OWASP Top 10: verkon tietoturva-aukot

01Mikä on OWASP ja Top 10 -lista?

OWASP (Open Worldwide Application Security Project) on avoin yhteisö, joka tuottaa ilmaisia resursseja, työkaluja ja oppaita ohjelmistojen tietoturvasta. Sen tunnetuin työ on muutaman vuoden välein päivitettävä Top 10 -lista.

Lista ei ole standardi eikä sertifikaatti vaan tietoisuutta lisäävä asiakirja. Se laaditaan yhdistämällä todellisen maailman avointa dataa ja asiantuntijoiden näkemyksiä, ja se sanoo kehittäjille: “kiinnitä huomio ensin näihin”. Tässä artikkelissa perustamme tarkastelun laajalti hyväksytyn vuoden 2021 version luokkiin.

Lista muuttuu ajan myötä; uusissa versioissa luokat vaihtavat paikkaa tai yhdistyvät. Tarkista ajantasainen versio aina viralliselta lähteeltä osoitteesta owasp.org.

021–2. Pääsynhallinta ja salaus

Listan kaksi ensimmäistä sijaa koskevat sitä, kenelle tietoa näytetään ja miten se suojataan. Molemmat kuuluvat yleisimpiin ja vakavimmat seuraukset aiheuttaviin aukkoihin, koska ne koskettavat suoraan asiakastietoja.

Rikkinäinen pääsynhallinta

Pääsynhallinnan virhe tarkoittaa, että käyttäjä pääsee käsiksi tietoon tai toimintoon, johon hänellä ei ole oikeutta. Klassinen esimerkki: asiakas muuttaa osoiterivin arvon siparis/1052 arvoksi 1053 ja näkee jonkun toisen tilauksen.

Torjunta on yksinkertaista mutta vaatii kurinalaisuutta: jokaisessa pyynnössä, palvelinpuolella, on kysyttävä uudelleen “saako tämä käyttäjä nähdä tämän tietueen?”. Oletuskäyttäytymisen tulee olla kieltäminen; pääsy avataan vain nimenomaisesti sallituissa tapauksissa.

Kryptografiset virheet

Arkaluonteisen tiedon siirtäminen tai tallentaminen salaamattomana kuuluu tähän ryhmään. Yleisimpiä esimerkkejä ovat salasanojen tallentaminen selkotekstinä tai heikoilla menetelmillä, HTTPS:n käyttämättä jättäminen ja vanhentuneet salausalgoritmit.

Salasanoille tulee käyttää tähän tarkoitukseen suunniteltuja hitaita tiivistemenetelmiä, kuten bcryptiä tai Argon2:ta, kaikki liikenne tulee siirtää HTTPS:n yli ja salausavaimet tulee säilyttää turvallisessa ympäristössä, ei koodissa.

033. Injektio: SQL-injektio ja XSS

Kun käyttäjältä tuleva data suoritetaan osana komentoa, kyse on injektioaukosta. Tunnetuimmat tyypit ovat SQL-injektio ja XSS. Vuoden 2021 listalla myös XSS käsitellään tämän luokan alla.

Mikä on SQL-injektio?

SQL-injektio tarkoittaa tietokantakyselyn muuttamista lomakkeeseen tai osoitekenttään kirjoitetuilla erikoismerkeillä. Hyökkääjä voi varastaa tai poistaa tietoja tai kirjautua luvatta sisään. Ratkaisu on muodostaa kysely valmistelluilla kyselyillä (prepared statement) eikä yhdistelemällä tekstiä.

// VÄÄRIN: käyttäjän syöte lisätään suoraan kyselyyn
$sql = "SELECT * FROM uyeler WHERE eposta = '" . $_POST['eposta'] . "'";

// OIKEIN: valmisteltu kysely
$stmt = $pdo->prepare('SELECT * FROM uyeler WHERE eposta = ?');
$stmt->execute([$_POST['eposta']]);
$uye = $stmt->fetch();

Mikä on XSS?

XSS (Cross-Site Scripting) tarkoittaa hyökkääjän kirjoittaman JavaScriptin sijoittamista sivulle. Kommenttikenttään syötetty skripti voi suorittua jokaisen sivun avaavan selaimessa. Perustoimet ovat asiayhteyteen sopiva escapointi tulostettaessa dataa ruudulle sekä Content Security Policy (CSP) -otsakkeen lisääminen.

echo htmlspecialchars($yorum, ENT_QUOTES, 'UTF-8');

044–5. Turvaton suunnittelu ja konfiguraatio

Nämä kaksi luokkaa koskevat koodia itseään enemmän päätöksiä: miten järjestelmä on rakennettu ja miten palvelin on asetettu. Hyvä uutinen on, että molemmat voidaan estää pitkälti prosesseilla ja tarkistuslistoilla.

Turvaton suunnittelu

Tämä luokka kuvaa koodivirheen sijaan suunnitteluvirhettä. Esimerkiksi salasanan palautuksessa luotetaan vain arvattavissa olevaan turvakysymykseen tai kampanjakoodia voi kokeilla rajattomasti. Vaikka koodi kirjoitettaisiin moitteettomasti, suunnitteluaukkoa ei tilkitä.

Torjunta on ajatella tietoturvaa kehityksen alussa eikä lopussa: uhkamallinnuksesta, väärinkäyttöskenaarioista ja yritysmäärän rajoittamisesta (rate limiting) tulee puhua suunnitteluvaiheessa.

Tietoturvan konfigurointivirheet

Tähän kuuluvat oletussalasanojen vaihtamatta jättäminen, palvelimen yksityiskohtien näyttäminen virheilmoituksissa, tarpeettomien palvelujen jättäminen auki tai hakemistolistauksen jääminen päälle. Nämä ovat usein helpoimmin hyödynnettäviä aukkoja.

Torjunta: laadi palvelimelle ja sovellukselle kirjallinen koventamislista, sulje virhetiedot tuotantoympäristössä, lisää tietoturvaotsakkeet (kuten HSTS, CSP, X-Content-Type-Options) ja tarkasta konfiguraatio säännöllisesti.

056–7. Komponentit ja tunnistautuminen

Kuudennen ja seitsemännen sijan riskit koskevat sovelluksen ulkopuolelta ottamia osia ja tapaa, jolla käyttäjän henkilöllisyys varmistetaan. Molemmat vaativat säännöllistä huoltoa; kertaalleen asennettuna ja unohdettuna ne eivät riitä.

Vanhat ja haavoittuvat komponentit

Moderni sovellus käyttää kymmeniä, jopa satoja ulkoisia kirjastoja. Kun jostakin niistä löytyy aukko, sovelluksesi joutuu vaaraan, vaikka et olisi tehnyt yhtään virhettä.

Torjunta: pidä lista käytetyistä komponenteista, seuraa tietoturvatiedotteita ja päivitä säännöllisesti. Pakettienhallintaohjelmien tarkastuskomennot helpottavat tätä. Käyttämättömän riippuvuuden poistaminen on myös yksi edullisimmista tietoturvatoimista.

npm audit
composer audit

Tunnistautumisen virheet

Tähän luokkaan kuuluvat heikkojen salasanojen salliminen, rajoittamattomalle kirjautumisyrityksille altistuminen, istuntotunnisteiden turvaton säilytys tai istunnon päättämättä jättäminen uloskirjautumisen yhteydessä.

Torjunta: rajoita yritysten määrää, tarjoa kaksivaiheinen tunnistautuminen, tarkista salasanat vuotaneita salasanalistoja vasten ja aseta istuntoevästeille HttpOnly-, Secure- ja SameSite-ominaisuudet.

068–10. Eheys, lokitus ja SSRF

Ohjelmiston ja datan eheys

Päivitysten, lisäosien tai automaattisen käyttöönottoputken suorittaminen ilman varmennusta avaa oven hyökkääjälle. Allekirjoitetut paketit, luotetut lähteet ja toimitusketjun valvonta ovat torjunnan perusta.

Lokituksen ja seurannan puute

Jos hyökkäystä ei huomata, vahinko kasvaa. Epäonnistuneet kirjautumiset, oikeusvirheet ja kriittiset toiminnot tulee kirjata, ja poikkeuksellisista tilanteista tulee tuottaa hälytys. Lokeihin ei saa kirjoittaa arkaluonteisia tietoja, kuten salasanoja.

SSRF

SSRF (Server-Side Request Forgery) tarkoittaa, että palvelin pakotetaan tekemään pyyntö käyttäjältä tulleeseen osoitteeseen. Tätä kautta hyökkääjä voi päästä sisäverkon palveluihin. Perustorjunta on sallittujen osoitteiden luettelon käyttö.

07Turvallisen koodauksen tarkistuslista

Useimmat aukot voi estää muutamalla perustavalla tottumuksella. Voit käyttää alla olevaa listaa koodikatselmoinneissa ja julkaisua edeltävissä tarkistuksissa. Käsittelimme testausprosessien yhteyttä tietoturvaan artikkelissa mikä on ohjelmistotestaus.

1. Älä koskaan luota syötteeseen: validoi kaikki syötteet palvelinpuolella.
2. Käytä valmisteltua kyselyä: älä muodosta SQL:ää yhdistelemällä tekstiä.
3. Escapoi tuloste: HTML-, URL- ja JavaScript-yhteyden mukaan.
4. Tarkista oikeudet jokaisessa pyynnössä: pelkkä piilottaminen käyttöliittymässä ei riitä.
5. Erota salaiset tiedot koodista: avaimet ympäristömuuttujiin tai holviin.
6. Pidä riippuvuudet ajan tasalla: suorita tarkastuskomento säännöllisesti.
7. Kirjaa ja seuraa: huomaa epäilyttävät tapahtumat.

08Turvallisten kielten ja työkalujen merkitys

Joitakin aukkotyyppejä voidaan vähentää myös kielen ja työkalujen valinnalla. Esimerkiksi muistiturvallisuuden tarjoavat kielet estävät pitkälti C:ssä ja C++:ssa yleiset puskurin ylivuotoaukot; kerroimme tästä artikkelissa mikä on Rust. Selaimessa turvallisessa hiekkalaatikossa toimiva WebAssembly perustuu samankaltaiseen eristyslogiikkaan.

Silti mikään kieli ei ratkaise pääsynhallinnan tai suunnittelun virheitä itsestään. Verkkosovellusten tietoturvasta suuri osa riippuu tiimin tottumuksista ja prosesseista.

Aurora Yazılımilla nämä perusperiaatteet toteutetaan kehitysprosessin osana toimialakohtaisissa ohjelmistoratkaisuissa, yrityksen kotisivuissa ja verkkokauppa-alustoissa.