Mitä jokaisen testaajan tulisi tietää tietoturvasta ja tietoturvatestauksesta

Pauli Kauppila, Secrays Oy

Sisältö

• Tietoturvan peruskomponentit• Uhka-analyysit• OWASP• Testaus ja tietoturvatestaus

11.4.2013

Tietoturva järjestelmissä

• Tietoturva on laatuominaisuus• Laadukas ohjelmisto on tietoturvallisempi kuin

huonolaatuinen • Toiminnalliset ja ei-toiminnalliset vaatimukset

• Tietoturvan testaaminen on hankalampaa kuin tiettyjen toiminnallisuuksien testaaminen

• Tietoturva ulottuu järjestelmän kaikkiin osiin• Osa tietoturvavaatimuksista voi olla liiketoiminnallisia ja selkeästi

määriteltävissä• Esimerkiksi session pituus

• Osa taas on johdettavissa järjestelmän luonteesta mutta liiketoiminnallinen määrittely vaikeampaa

11.4.2013

Testaamisen ongelmat

11.4.2013

Suunniteltu järjestelmä ja toiminnallisuus

Testaus määriteltyä toiminnallisuutta vasten

Toteutettu järjestelmä

Testaus?

Sovellusten tietoturvariskit

11.4.2013

Lähde: OWASP https://www.owasp.org/index.php/Top_10_2013-Risk

Tietoturvan peruskomponentit

11.4.2013

Tietoturvan peruskomponentit

• Tietoturvaominaisuuksia voidaan tarkastella loogisen jaottelun avulla

• Luottamuksellisuus (Confidentiality)• Eheys (Integrity)• Saatavuus (Availability)• Kiistämättömyys (Nonrepudiation)• Autentikointi (Authentication)• Autorisointi (Authorization)

11.4.2013

Confidentiality

Integrity

Availability

Nonrepudiation

Authentication

Authorization

Luottamuksellisuus

• Useimmiten IT-tietoturvaa ajateltaessa mieleen tulee ensimmäisenä salaus

• Salauksen avulla toteutetaan luottamuksellisuutta• Lisäksi tarvitaan todentamisen ja

valtuuttamisen mekanismit

• Salaus voi olla symmetristä tai epäsymmetristä

• Salauksen toteuttaminen järjestelmiin on vaativaa• Laskentaintensiteetti• Salausavainten hallinta• Varmenteiden hallinta

• Mietittävä tarkkaan mikä on riski ja haluttu luottamuksellisuuden taso

11.4.2013

Integrity

Availability

Nonrepudiation

Authentication

Authorization

Confidentiality

Eheys

• Eheydellä tarkoitetaan että sanoman vastaanottaja voi luottaa sanoman säilyneen muuttumattomana lähettäjältä

• On hyvä huomata, että salaus pelkästään ei takaa eheyttä

• Eheyden mekanismeja ovat allekirjoitukset• Allekirjoituksen ja salauksen avulla

toteutetaan eheys ja luottamuksellisuus

• Allekirjoitukset johtavat kiistämättömyyteen

11.4.2013

Confidentiality

Availability

Nonrepudiation

Authentication

Authorization

Integrity

Saatavuus

• Järjestelmän toimintavarmuuden turvaaminen• Ohjelmistot• Laitteet• Toipuminen poikkeustilanteissa

• Myös häiriönsietokyky vaikuttaa saatavuuteen• “Robustisuus”• Huomioitava järjestelmän/ohjelmiston

kehittämisessä ja tuotantoympäristön konfiguroinnissa

• Riskiarviointi tahallisille ja tahattomille häiriöille

11.4.2013

Confidentiality

Integrity

Availability

Nonrepudiation

Authentication

Authorization

Kiistämättömyys ja allekirjoitukset

• Kiistämättömyys tarkoittaa, että sanoman lähettäjä on yksikäsitteisesti todennettavissa • Lähettäjä ei voi kiistää

lähettäneensä sanomaa

• Tyypillisesti salauksen ja allekirjoitusten yhteydessä käytetään varmenteita

11.4.2013

Confidentiality

Integrity

Availability

Nonrepudiation

Authentication

Authorization

12

Sanoma

Sanomaotsake

Liiketoiminnallinen sanoma

Sanoma

Lähettäjä Vastaanottaja

1

2

3

4

1) Lähettäjä liittää oman varmenteensa sanomaotsakkeeseen

2) Lähettäjä laskee sanomasta ns. Tiivisteen ja salaa sanoman yksityisellä avaimellaan

3) Vastaanottaja todentaa kutsujan sanomatsakkeessa tulevan varmenteen perusteella4) Vastaanottaja purkaa sanomasalauksen varmenteesta saatavalla lähettäjän julkisen avaimella ja laskee tiivisteen uudelleen ja tarkistaa sanomatiivisteen vastaavuuden

Salattu tietoliikenneyhteys

Varmenne

2

Allekirjoitus

Liiketoiminnallinen sanoma

Sanomaotsake

Varmenne

X.509 varmenne ja allekirjoitus

Yksityinen avain

Allekirjoitus

Julkinen avain

Autentikointi

• Autentikointi eli todentaminen• Autentikoinnilla varmennetaan käyttäjän

identiteetti• Tyypillinen todennusmekanismi on

käyttäjätunnus ja salasana

• Vahva tunnistus tarkoittaa, että käyttäjän identiteetti varmennetaan vähintään kahdella seuraavasta kolmesta• Jotain minkä käyttäjä tietää (salasana)• Jotain mikä käyttäjällä on (laite)• Jotain käyttäjän ominaisuuksiin liittyen

(sormenjälki)

• Tyypillinen tapa toteuttaa vahva autentikointi• Käyttäjätunnus ja salasana sekä lisäksi erillinen

autentikointikanava: puhelinviesti, autentikointitoken tai –ohjelmisto (esim. puhelimessa).

11.4.2013

Confidentiality

Integrity

Availability

Nonrepudiation

Authorization

Authentication

Auktorisointi (valtuutus)

• Käyttäjän profilointi todennetun identiteetin perusteella

• Valtuutusprosessin avulla käyttäjälle tarjotaan (vain) hänelle kuuluvat palvelut• Roolipohjaiset käyttövaltuudet• Ryhmään liittyvät oikeudet• Rooli+käyttäjä+tietosisältö yhdessä

määrittävät käyttäjän oikeudet

11.4.2013

Confidentiality

Integrity

Availability

Nonrepudiation

Authentication

Authorization

Uhka-analyysi

11.4.2013

STRIDE uhkien tunnistaminen

Uhka Määrittely Esimerkki

Spoofing”Väärentäminen”

Toisena esiintyminen Esimerkiksi sanomakutsuun liittyvän identiteetin väärentäminen ( tai väärentyminen)

Tampering”Peukalointi”

Tiedon muuttaminen Tiedoston, sanoman tai tietokannan sisällön muokkaus

Repudiation”Kiistäminen”

Kiistetään jonkun toimenpiteen suorittaminen

“En käynyt sillä sivulla…” “En lähettänyt sitä viestiä”

Information DisclosureTiedon paljastuminen

Tieto näkyy jollekin jolla ei ole oikeutta nähdä sitä

Esimerkiksi tyypillisesti web-sovelluksessa: voidaanko kuunnella liikennettä edustan ja kannan välillä?Sanomien tai aineistojen välivarastointi ja oikeudet?

Denial of ServicePalvelunesto

Joko tahallinen tai tahaton palvelunestyminen asiakkaalta

Julkisen palvelun rajoittamaton käyttöHuono tai olematon varautuminen kuormituspiikkeihinSyötteiden validoinnin puutteet

Elevation of Privilege, oikeuksien nostaminen

Ei auktorisoida Admin-käyttö, toisen asiakkaan tietojen luku

11.4.2013

DREAD uhkien luokittelu

11.4.2013

Uhka Määrittely Esimerkki

Damage Potential If a threat exploit occurs, how much damage will be caused?

0 = Nothing5 = Individual user data is compromised or affected.10 = Complete system or data destruction

Reproducibility How easy is it to reproduce the threat exploit?

0 = Very hard or impossible, even for administrators of the application.5 = One or two steps required, may need to be an authorized user.10 = Just a web browser and the address bar is sufficient, without authentication.

Exploitability What is needed to exploit this threat? 0 = Advanced programming and networking knowledge, with custom or advanced attack tools.5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools.10 = Just a web browser

Affected Users How many users will be affected? 0 = None5 = Some users, but not all10 = All users

Discoverability How easy is it to discover this threat? 0 = Very hard to impossible; requires source code or administrative access.5 = Can figure it out by guessing or by monitoring network traces.9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine.10 = The information is visible in the web browser address bar or in a form.

OWASP

11.4.2013

OWASP

• Open Web Application Security Project • Vapaaehtoinen yhteisö ja keskustelufoorumi, jonka

tavoitteena on kasvattaa tietoisuutta turvallisen ohjelmistokehityksen menetelmistä• Lähtökohtana ”open source” ajattelu• OWASP myös pyrkii kehittämään open source –ratkaisuja

tietoturvahaasteisiin• OWASP Helsinki järjestää kaikille avoimia tilaisuuksia 3-4 kertaa

vuodessa

• OWASP Top 10 on lista yleisimmistä haavoittuvuuksista• Uusitaan muutaman vuoden välein

• OWASP on julkaissut myös useita oppaita• OWASP Developer’s guide, Testing guide

11.4.2013

OWASP Top 10

11.4.2013

OWASP Top 10: A1 Injection

• Tyypillisesti johtuu siitä, että ohjelmistossa luotetaan sanomaan ja sen parametreihin

• Klassinen tapaus on syötteen tarkistus käyttöliittymällä (selain) mutta ei palvelimella• Web-sovelluksessa syötteen tarkistus käyttöliittymällä parantaa

käyttökokemusta mutta ei tietoturvaa• Syötetarkistukset on aina tehtävä myös palvelinosuudessa

• Muoto, pituus, sallitut merkit

• Suurissa järjestelmissä palvelut saattavat olla koosteisia, ja niiden kutsureitit monikanavaisia• Kutsuja selaimelta, mobiilisovellukselta, palvelimilta• Puolustuslinjana palvelinkutsujen ohjaaminen keskitetyn tietoturvallisen

väylän kautta

11.4.2013

OWASP Top 10: A3 Cross-Site Scripting (XSS)• Käyttäjän antama syöte välitetään selaimelle sellaisenaan

tarkastamatta ja käsittelemättä sitä ensin• Tämä mahdollistaa hyökkääjältä tulevien komentojen

suorittamisen sovelluksen alaisuudessa• Komennoilla voidaan muuttaa selaimessa esimerkiksi sivuston

ulkoasua tai kaapata sivuston istuntotunnisteet

• Puolustuslinjat• HTML escaping

• Merkistön käsittelytekniikka, jossa tulostemerkistöä käsitellään datana eikä tulkinnallisesti merkitsevinä merkkeinä/kombinaatioina

• Oikein tehtynä escaping ei aiheuta vahinkoa, merkit kaiuttuvat selaimessa oikein: “<“ on “&#60;” on “<“

• Lisäksi syötetarkistus kuten aiemmin mainittiin

11.4.2013

OWASP ASVS

• ASVS Application Security Verification Standard

• ASVS määrittelee tietoturvan kannalta oleelliset tekniset kontrollit, jotka tulee tarkastaa testausprosessissa

• Kyseessä on erittäin laaja standardi, jota voi soveltaa eri vaiheissa• Sovellusten kehitys• Sopimukset toimittajien kanssa• Testaussuunnittelussa

11.4.2013

V1 - Security Architecture Documentation Requirements V2 - Authentication Verification Requirements V3 - Session Management Verification Requirements V4 - Access Control Verification Requirements V5 - Input Validation Verification Requirements V6 - Output Encoding/Escaping Verification Requirements V7 - Cryptography Verification Requirements V8 - Error Handling and Logging Verification Requirements V9 - Data Protection Verification Requirements V10 - Communication Security Verification Requirements V11 - HTTP Security Verification Requirements V12 - Security Configuration Verification Requirements V13 - Malicious Code Search Verification Requirements V14 - Internal Security Verification Requirements

Testaus ja tietoturvatestaus

11.4.2013

Toiminnallinen testaus ja tietoturvatestaus

• Toiminnallinen testaus pyrkii todentamaan ohjelmiston toiminnan määrittelyn mukaisesti

• Kuten alussa todettiin laatuominaisuuksien kannalta se ei ole riittävää• Ohjelmisto voi toimia määritysten mukaisesti, mutta

• ei ole suorituskykyinen• ei ole häiriösietoinen• avaa mahdollisuuksia väärinkäyttötapauksille, tahallisille tai

tahattomille

• Voidaanko (liike)toiminnallisessa testauksessa tehdä mitään tietoturvan parantamiseksi?• Ilman haavoittuvuusskannereiden opettelua ja käyttöä

Ehdotuksia

• Väärinkäyttötapaukset• Riski- tai uhka-analyysin perusteella• Testitapaukset, joista osa toteutettavissa ”normaalin” testauksen

puitteissa

• Tietyn tyyppisten toiminnallisuuksien tunnistaminen • Sisäänkirjaus• Käyttövaltuudet• Uloskirjaus

• Seuraavassa esimerkkejä ASVS:n pohjalta

11.4.2013

Autentikoinnin testaaminen

• Verify that all pages and resources require authentication except those specifically intended to be public.• Kokeillaan että jokainen sivu vaatii autentikoinnin, esimerkiksi

kirjoittamalla sivun osoite selaimeen

• Verify that all authentication decisions are logged• Tarkistetaan että sisäänkirjautumisesta ja sen epäonnistumisesta

kirjataan lokiin

Sessionhallinnan testaaminen

• Verify that sessions are invalidated when the user logs out.• Kokeillaan että sessioon ei pääse esimerkiksi selaimen back-

näppäimellä tai kirjoittamalla osoiteriville uudestaan sovelluksen osoite

• Verify that sessions timeout after a specified period of inactivity.• Testataan määrittelyn mukaisesti

• Verify that all pages that require authentication to access them have logout links.• Tarkistetaan jokaiselta sivulta

• Verify that the session id is changed or cleared on logout.• Tarkistetaan selaimen session id:n muuttuminen

Auktorisoinnin testaaminen

• Verify that users can only access services for which they possess specific authorization.• Tarkistetaan että jokaisella roolilla pääse vain sille tarkoitettuihin

toimintoihin

• Verify that users can only access secured URLs for which they possess specific authorization• Tarkistetaan että jokaisella roolilla pääse vain sille tarkoitettuihin

osoitteisiin

Sisällön tarkistaminen

• Verify that all input validation failures result in input rejection or input sanitization.• Esimerkiksi testataan postinumero-kenttään kirjaimia ja enemmän

kuin viisi merkkiä• Tarkistetaan vakuutusnumeron muoto

• Verify that all untrusted data that are output to HTML (including HTML elements, HTML attributes, JavaScript data values, CSS blocks, and URI attributes) are properly escaped for the applicable context.• Käytetään yksinkertaista scriptiä syöttökentissä tai URLissa

Virheen hallinta

• Verify that that the application does not output error messages or stack traces containing sensitive data that could assist an attacker, including session id and personal information.• Tarkistetaan ettei virheviestit sisällä sensitiivistä informaatiota

Kiitos!pauli@secrays.com

11.4.2013

@pkauppila