Discussion:
web-app security jutskaa
(too old to reply)
marko
2003-08-04 21:55:34 UTC
Permalink
Terve..

Kuvitellaan, että meillä on firen takana web-palvelin jossa pyörii asp,
php tai perl pohjaiset sivut... Lisäksi meillä on jokin SQL tietokanta
erillisellä serverillä josta web-palvelin käy hakemassa dynaamista
tietoa ja voi myös tarvittaessa tallentaa sitä.

Kuvitellaan, että joku on kehittänyt tuolle saitille web-applikaation,
jossa asiasta kiinnostuneet pääsevät tekemään tietokannasta hakuja
vaikka eri porakoneista ja saavat vasteeksi teknistä tietoa laitteista.
Hakuja voi tehdä eri arvojen perusteella, esimerkiksi valmistajan nimi,
kierrosnopeudet ja niin edelleen.

Lisäksi saitilla on yksinkertainen "forum", tai vieraskirjan tyylinen
sovellus jonne kävijät voivat antaa kommenttejaan, ehdotuksiaan tai
vaikkapa keskustelemaan siitä että mikä terä käy parhaiten kakkosnelosen
poraamiseen. Tämä data tallentuu tietokantaan josta vastaavasti haetaan
info kun katsotaan saitilla mitä kaikkea "forumiin" on kirjoitettu.

Miten te varmistuisitte tai pyrkisitte rajoittamaan sitä, että joku
ilkeä krakkeri ei pääsisi hyväksikäyttämään tätä saittia omiin
tarkoituksiinsa tai muuten vaan tekemään ilkivaltaa?

Ajatelkaa YLEISELLÄ tasolla, älkää keskittykö esimerkiksi perl tai MS
SQL-serverin saloihin.. Pyrkikää myös kevyehkösti perustelemaan
minkä takia tekisitte jonkin asian juuri sillä tavalla kuin itse
ajattelitte. Kirjaa ei tarvitse kirjoittaa ;-)

Tarkoitus ei ole saada aikaan mitään ohjelmointi-threadia vaan
keskustelua siitä mitä kaikkea web-applikaation turvallisuuteen liittyy
ja mitä pitäisi ottaa huomioon. Ja toivottavasti Olkinuket, Ad Hominemit
ja hillittömät flame-postaukset pysyvät tästä threadista poissa, muuten
palaa pinna.

Jos aihe-alue on uusi ja tuntuu kiinnostavalta, kannattaa käydä
tutustumassa seuraavaan saittiin: http://www.owasp.org/index

-m-

PS. oma kokemukseni tällä saralla ei ole vielä kovin suuri, mutta
kiinnostusta löytyy.
--
- Liquid Information - http://www.liquidinfo.net
- E-mail: Remove NOS_PAM if present in address (Usenet)
- PGP: http://www.liquidinfo.net/about.html
--
Aggro
2003-08-04 22:31:22 UTC
Permalink
Post by marko
Terve..
Kuvitellaan, että meillä on firen takana web-palvelin jossa pyörii asp,
php tai perl pohjaiset sivut... Lisäksi meillä on jokin SQL tietokanta
erillisellä serverillä josta web-palvelin käy hakemassa dynaamista
tietoa ja voi myös tarvittaessa tallentaa sitä.
Kuvitellaan, että joku on kehittänyt tuolle saitille web-applikaation,
jossa asiasta kiinnostuneet pääsevät tekemään tietokannasta hakuja
Lisäksi saitilla on yksinkertainen "forum", tai vieraskirjan tyylinen
sovellus jonne kävijät voivat antaa kommenttejaan, ehdotuksiaan tai
Miten te varmistuisitte tai pyrkisitte rajoittamaan sitä, että joku
ilkeä krakkeri ei pääsisi hyväksikäyttämään tätä saittia omiin
tarkoituksiinsa tai muuten vaan tekemään ilkivaltaa?
3 reittiä sisään. Helppousjärjestyksessä (helpolla tarkoitan sitä, että
prosentuaalisesti suurin osa murtautumista harkitsevista pääsee sisään
helpommasta aukosta)

1. Vanhat tunnetut aukot tunnetuissa ohjelmissa joita ei ole paikattu.
Tähän auttaa yksinkertaisesti se, että on ajantasalla ja päivittää
softia. Tämä tuntuu todella yksinkertaiselta ja helpolta neuvolta, mutta
se on edelleen se eniten käytetty reitti.

2. Aukot omatekemissä ohjelmissa. Hyvät, tietoturvaa ymmärtävät
koodarit. Hyvät tietoturvaa ymmärtävät testaajat. On lähes mahdotonta
tehdä 100% varmaa softaa, mutta aina voi yrittää.

3. Tuntemattomat aukot tunnetuissa softissa. Et oikeastaan voi tehdä
paljoakaan. Paitsi tietty minimoida murtautujan mahdollisuudet tehdä
haittaa. Älä aja ohjelmia admin/root tunnuksilla, jolloin murtautujat
eivät saa koko konetta valtaansa. Käytä palomuuria, sillä se voi
ehkäistä joidenkin tuntemattomien aukkojen hyödyntämisen, ikäänkuin
sivutuotteena.

( No, jätin tästä pois salasanojen kuuntelun, virusten ja troijalaisten
vastaanotto serverikoneella ja muuta pientä, mikä pitäisi olla
itsestäänselvää ylläpitäjälle. Jos esimerkiksit päästät murtomiehet
istumaan pariksi minuutiksi yksin serverikoneen ääreen, voit olla varma,
että he pääsevät sisään. )
Mika Yrjola
2003-08-05 08:06:05 UTC
Permalink
Post by Aggro
3 reittiä sisään. Helppousjärjestyksessä (helpolla tarkoitan sitä,
että prosentuaalisesti suurin osa murtautumista harkitsevista pääsee
sisään helpommasta aukosta)
1. Vanhat tunnetut aukot tunnetuissa ohjelmissa joita ei ole
paikattu. Tähän auttaa yksinkertaisesti se, että on ajantasalla ja
päivittää softia. Tämä tuntuu todella yksinkertaiselta ja helpolta
neuvolta, mutta se on edelleen se eniten käytetty reitti.
3. Tuntemattomat aukot tunnetuissa softissa. Et oikeastaan voi tehdä
paljoakaan. Paitsi tietty minimoida murtautujan mahdollisuudet tehdä
haittaa. Älä aja ohjelmia admin/root tunnuksilla, jolloin murtautujat
eivät saa koko konetta valtaansa. Käytä palomuuria, sillä se voi
ehkäistä joidenkin tuntemattomien aukkojen hyödyntämisen, ikäänkuin
sivutuotteena.
Ja ykköseen & kolmoseen liittyen tulee myöskin mieleen, että
asennettuna pidetään vain ne softat mitä koneessa oikeasti tarvitsee
olla, eikä tungeta sinne www-palvelimen seuraksi vaikka C-kääntäjää,
jotain verkkoa kuuntelevia turhia palveluita, Nethackia jota
ylläpitäjä pelaa silloin kun on tylsää jne.
marko
2003-08-05 15:53:38 UTC
Permalink
On 05 Aug 2003 11:06:05 +0300
Post by Mika Yrjola
sillä se voi ehkäistä joidenkin tuntemattomien aukkojen
hyödyntämisen, ikäänkuin sivutuotteena.
Ja ykköseen & kolmoseen liittyen tulee myöskin mieleen, että
asennettuna pidetään vain ne softat mitä koneessa oikeasti tarvitsee
olla, eikä tungeta sinne www-palvelimen seuraksi vaikka C-kääntäjää,
jotain verkkoa kuuntelevia turhia palveluita, Nethackia jota
ylläpitäjä pelaa silloin kun on tylsää jne.
Ihan valideja pointteja.

Vaikka kaikki patchaus ja muu olisi hienolla mallilla, niin bugi
web-applikaatiossa saattaa romuttaa sen kaiken sallimalla hyökkääjän
tehdä koiruuksiaan. Firehän ei sinänsä estä tätä tapahtumasta,
koska sehän nimenomaan sallii pääsyn web-applikaatioon. Se vain
varmistaa, että muut auki olevat servicet ja jutut eivät ole
internettiin avoinna.

IDS:n käyttö on varmasti järkevää, toimii hälytyskellona. Mutta
valitettavasti silloin on jo vahinko tapahtunut kun se älähtää. SSL taas
estää IDS:n käytön vaikka se suojaisikin käyttäjän ja serverin välistä
yhteyttä urkinnalta.

Sitä voi vain pyrkiä konfiguroinneilla ja säädöillä minimoimaan
mahdolliset vahingot siltä varalta jos web-applikaatiossa onkin jokin
bugi jota developerit eivät ole huomanneet.

-m-
--
- Liquid Information - http://www.liquidinfo.net
- E-mail: Remove NOS_PAM if present in address (Usenet)
- PGP: http://www.liquidinfo.net/about.html
--
Jari Ristiranta
2003-08-05 00:09:10 UTC
Permalink
Post by marko
Miten te varmistuisitte tai pyrkisitte rajoittamaan sitä, että joku
ilkeä krakkeri ei pääsisi hyväksikäyttämään tätä saittia omiin
tarkoituksiinsa tai muuten vaan tekemään ilkivaltaa?
Syötteen tarkistaminen. Erityisesti kannattaa pitää huolta, ettei
lomakkeiden parametreja anneta sellaisenaan esim. tietokannalle tai
shelliin.
Jori Tursa
2003-08-05 09:01:37 UTC
Permalink
Tässä muutama asia, ei tärkeimmät, eikä välttämättä ihan oikeinkaan.

Jos systeemin tulee salasanantunnistus, koita pitää salasanat tietokannassa,
ts. lähetä käyttäjätunnus ja salasana tietokantaan testattavaksi.
Tietokantaan kannattaa mahdollisuuksien rajoissa rakentaa eri
käyttöoikeustasoja, jos porakonetiedot ovat erinomaisen salaisia.
Windows-ympäristössäni _omasta_ mielestäni nt-integroitu salasanasuojaus on
omia viritelmiä parempi.

Jos käytät Microsoftin serverisoftia, lue heidän ohje turvallisen
web-palvelimen asentamiseen, se on käytännössä lista kaikista turhista
käyttäjäoikeuksista ja palveluista, jotka tietysti poistetaan. Tämmöistä
listaa pitänee varmasti moni muukin. (Turha vastata, että Microsoftin
palvelimet on aina epäturvallisia :-).

ASP tai PHP ovat kielenä (teoreettisesti?) turvallisempia kuin mikään
cgi-bin -rajapintaa käyttävä tai muuten ohjelmia tai COM-palikoita ajava
systeemi, koska palvelin ei varsinaisesti suorita koodia, vaan ajaa
skriptiä. Joka tapauksessa jää kaikki exet ja dll-filet ajamatta
palvelimella, jos käyttäjänä on selailija (tämä taas Microsoft IISissä).
Jukka Mustasilta
2003-08-05 14:12:25 UTC
Permalink
Post by marko
Miten te varmistuisitte tai pyrkisitte rajoittamaan sitä, että joku
ilkeä krakkeri ei pääsisi hyväksikäyttämään tätä saittia omiin
tarkoituksiinsa tai muuten vaan tekemään ilkivaltaa?
Varmista, että urlissa ei missään vaiheess esiinny tavaraa, joka menee
sellaisenaan SQL-kyselyyn.
Esim, jos kysely olisi vaikka

SELECT nimi FROM porakoneet WHERE malli = :muuttuja

niin voisin ilkeyksissäni syöttää webbisivun formilta kohtaan muuttuja esim
stringin

*' AND 1=1 OR malli = 'x

jolloin saisin palautteena kaikki ko. tietokantataulun tiedon, sisällytän
siis SQL-kyselyä muuttujaan ja jos sovellus ei esim poista heittomerkkejä
niin tällainen mahdollisuus aukeaa, lienee mahdollista syöttää paljon
muitakin SQL-komentoja, hakea tietoa toisista tietokannoista jopa

t:Jukka
Jari Fredriksson
2003-08-05 14:30:32 UTC
Permalink
Post by Jukka Mustasilta
Esim, jos kysely olisi vaikka
SELECT nimi FROM porakoneet WHERE malli = :muuttuja
niin voisin ilkeyksissäni syöttää webbisivun formilta kohtaan
muuttuja esim stringin
*' AND 1=1 OR malli = 'x
jolloin saisin palautteena kaikki ko. tietokantataulun tiedon,
Missä kannassa noin voi käydä? Vai onko se joku ODBC-bugi?

Ei ainakaan Oracleen pitäisi millään lailla mennä tuollainen, tai
vastaavakaan läpi. :muuttuja on muuttuja, ja sen arvo on sen arvo. Itse
lauseeseen sen ei pitäisi vaikuttaa,
Timo Voipio
2003-08-05 14:51:57 UTC
Permalink
Post by Jari Fredriksson
Missä kannassa noin voi käydä? Vai onko se joku ODBC-bugi?
MySQL:n manuaalissa tuosta ainakin varoitettiin.
--
Timo Voipio | Helsinki, Finland | ICBM at: 60 11.800 N 024 52.760 E
GeekCode ver 3: GU>CC d s-: a--- C++ UL(+)$>+++$ P+>+++ L++(+) E- W++ N++
o? K? w O M- V- PS PE Y+ PGP+ t 5++ X R tv- b++(++++) DI+ D G e- h! r !y
Remove +newsharvested to e-mail me | Poista +newsharvested jos meilaat
marko
2003-08-05 16:03:40 UTC
Permalink
On Tue, 05 Aug 2003 17:51:57 +0300
Post by Timo Voipio
Post by Jari Fredriksson
Missä kannassa noin voi käydä? Vai onko se joku ODBC-bugi?
MySQL:n manuaalissa tuosta ainakin varoitettiin.
Kyse on Input Validationista, eli käyttäjän syötteen tarkistamisesta. Ei
saisi koskaan luottaa mihinkään mitä käyttäjä lähettää serverille, vaan
pitäisi aina tarkistaa onko tieto sitä mitä se web-applikaatio odottaa.

Hyökkääjä pystyy käytetyn server-side kielen ja kannan puitteissa
tekemään erilaisia asioita, esimerkiksi tekemään ylimääräisiä kyselyitä
kannasta, lisäämään/poistamaan tietueita, ehkä ajamaan komentojakin
tietokannassa. Jotkut toiminnallisuudet web-applikaatiossa taas voivat
sallia komentojen ajamisen tjsp sillä serverillä ja niin edelleen.

Jukan esimerkki on ihan hyvä.

Itse tekisin input validation rutiinin sen mukaan miten minä odotan
applikaatiota käytettävän, eli jos johonkin kenttään halutaan pelkkää
tekstiä, silloin tarkistaisin, että käyttäjän input todellakin on
tekstiä, eikä esimerkiksi numeroita (tai erikoismerkkejä joilla monesti
se vahinko saadaan aikaiseksi). Blacklist kielletyistä merkeistäkin käy
ja filtteröi ne pois käyttäjän inputista.

Escapointi on myös yksi tapa tehdä se, eli esimerkiksi <> -merkit
menettävät ns. html-merkityksensä ja niitä ei pystyisi käyttämään väärin
(esim injectoimaan html:ää esimerkkinä toimivaan "forumiin"). Sitä miten
tämä itseasiassa tapahtuu, en tiedä (voiko joku valaista?).

-m-
--
- Liquid Information - http://www.liquidinfo.net
- E-mail: Remove NOS_PAM if present in address (Usenet)
- PGP: http://www.liquidinfo.net/about.html
--
JJ
2003-08-05 20:37:24 UTC
Permalink
"marko" <***@liquidNOS_PAMinfo.net> wrote in message news:***@liquidNOS_PAMinfo.net...
Escapointi on myös yksi tapa tehdä se, eli esimerkiksi <> -merkit
menettävät ns. html-merkityksensä ja niitä ei pystyisi käyttämään väärin
(esim injectoimaan html:ää esimerkkinä toimivaan "forumiin"). Sitä miten
tämä itseasiassa tapahtuu, en tiedä (voiko joku valaista?).

Jos nyt vaikka ajatellaan, että keskustelufoorumissa on jokin
taulukkorakenne, jonka jokin solu tms. saa arvonsa suoraan käyttäjän
antamasta syötteestä. Tällöin joku voisi kirjoittaa syötteeksi esim.

<script>alert('Injected JavaScript in a cell :)')</script>

Jolloin se näyttäisi hötömölönä taulukossa seuraavalta:

<td>
<script>alert('Injected JavaScript in a cell :)')</script>
</td>

Ja niin käyttäjien (ja ylläpidon) riemastukseksi jokainen sivun lataaja
saisi virkistävän popupin näytöllensä.

JJ
marko
2003-08-05 21:30:26 UTC
Permalink
On Tue, 5 Aug 2003 23:37:24 +0300
Post by marko
Escapointi on myös yksi tapa tehdä se, eli esimerkiksi <> -merkit
Ja niin käyttäjien (ja ylläpidon) riemastukseksi jokainen sivun
lataaja saisi virkistävän popupin näytöllensä.
Kyllä. Kuten mainitsin, tästä en ollut ihan varma miten escapointi
toimii, eli sallitaan lopulta ne <>-tagit ihan normaalina tekstinä eikä
HTML:nä. Ymmärtääkseni tämänkaltainen toiminnallisuus on mahdollista?
Korjaa jos olen väärässä.. (eli joku haluaa vaikka kertoa poranterän
kestävyyden johonkin toiseen terään verraten tjsp)

-m-
--
- Liquid Information - http://www.liquidinfo.net
- E-mail: Remove NOS_PAM if present in address (Usenet)
- PGP: http://www.liquidinfo.net/about.html
--
marko
2003-08-05 21:37:42 UTC
Permalink
On Wed, 6 Aug 2003 00:30:26 +0300
Post by JJ
Ja niin käyttäjien (ja ylläpidon) riemastukseksi jokainen sivun
lataaja saisi virkistävän popupin näytöllensä.
Ja mainittakoot, että olen törmännyt tämänkaltaisiin "virheisiin" eri
saiteilla., eli tavallaan cross-site scriptingiin. En vain tässä
tapauksessa ole kunnolla ymmärtänyt miten escapointia voidaan käyttää
hyödyksi.

-m-
Jori Tursa
2003-08-05 22:06:15 UTC
Permalink
Post by marko
Korjaa jos olen väärässä.. (eli joku haluaa vaikka kertoa poranterän
kestävyyden johonkin toiseen terään verraten tjsp)
Web-sovelluksessa vaihdat tallennettavan käyttäjäsyötteen ">" ja "<"-merkit
hötömölön vastaaviksi, eli "&gt;" ja "&lt;" . Onko sitten parempikin tapa,
en tiedä.
marko
2003-08-05 22:07:58 UTC
Permalink
On Wed, 6 Aug 2003 01:06:15 +0300
Post by Jori Tursa
Web-sovelluksessa vaihdat tallennettavan käyttäjäsyötteen ">" ja
parempikin tapa,
Kiitos selvennyksestä, myös JJ:lle. Itse tekninen toutetus on minulle
outo-lintu... Eli ilmeisesti vain korvataan tietyt merkit tietyllä
stringillä, ja se on siinä?

-m-
--
- Liquid Information - http://www.liquidinfo.net
- E-mail: Remove NOS_PAM if present in address (Usenet)
- PGP: http://www.liquidinfo.net/about.html
--
JJ
2003-08-05 21:33:23 UTC
Permalink
Post by marko
Escapointi on myös yksi tapa tehdä se, eli esimerkiksi <> -merkit
menettävät ns. html-merkityksensä ja niitä ei pystyisi käyttämään väärin
(esim injectoimaan html:ää esimerkkinä toimivaan "forumiin"). Sitä miten
tämä itseasiassa tapahtuu, en tiedä (voiko joku valaista?).
Ja kun väsyneenä lukee, niin usein lukee huonosti. Tarkoitit ilmeisesti,
kuinka se escapetus tehdään? En tiedä onko PHP:ssa tai Perlissä valmiita
kirjastoja, mutta nopeastihan sitä yhden encoder / decoder mokkulan tekee,
joka muuntaa esim. < ja > merkit selaimelle yst�v�lliseen muotoon (tyyliin <script> --> &lt;script&gt;).

JJ
Jori Mantysalo
2003-08-06 05:03:48 UTC
Permalink
Tämäkään ei välttämättä riitä. Jos esim. pääsee vieraskirjaan syöttämään
kotisivunsa URLin, niin sen tilalle voi laittaa javaskriptiä ellei
tässä tehdä muuta tarkistusta kuin <- ja >-merkkien eskapointi.
--
Auta tiedettä. Lahjoita rikkinäinen kannettavan tietokoneen DVD-asema.
Lisätietoja saat sähköpostilla.
jussi jaakonaho
2003-08-05 16:13:34 UTC
Permalink
Post by Jari Fredriksson
Ei ainakaan Oracleen pitäisi millään lailla mennä tuollainen, tai
vastaavakaan läpi. :muuttuja on muuttuja, ja sen arvo on sen arvo. Itse
lauseeseen sen ei pitäisi vaikuttaa,
-menee oracleen,kuin muihinkin. sql injektio ei ole tietokantasidonnaista
(eli että toimii vain jossain) vaan enemmän websovellus- ohjelmointiongelma.
eri kielten ja kantojen välillä on tietty joitain erilaisuuksia.


_jussi
Jukka Mustasilta
2003-08-05 18:27:11 UTC
Permalink
Post by Jari Fredriksson
Post by Jukka Mustasilta
*' AND 1=1 OR malli = 'x
Missä kannassa noin voi käydä? Vai onko se joku ODBC-bugi?
Ei ainakaan Oracleen pitäisi millään lailla mennä tuollainen, tai
Se varmasti riippuu toteutuksesta. Jos SQL-lause rakennetaan sovelluksessa
niin se ei tietokannan merkkiä katso, meneekö tuollainen läpi.
Jos käytetään enemmän ohjelmointirajapinnan ominaisuuksia ja parametroituja
kyselyjä niin sitten tuon toimivuus jo riippuu monesta asiasta ja niiden
versioista.

Tarkoitus oli antaa yksinkertainen esimerkki kysyjälle siitä, mikä voisi
olla mahdollista tietokantakytkyn kautta. Samaan lopputulokseen päässee
monimutkaisemmillakin keinoilla.

t:Jukka
Juha Autero
2003-08-05 21:23:20 UTC
Permalink
Post by Jari Fredriksson
Missä kannassa noin voi käydä? Vai onko se joku ODBC-bugi?
Ei ainakaan Oracleen pitäisi millään lailla mennä tuollainen, tai
vastaavakaan läpi. :muuttuja on muuttuja, ja sen arvo on sen arvo. Itse
lauseeseen sen ei pitäisi vaikuttaa,
Yleensä tuo riski onkin olemassa silloin kun ei käytetä muuttujia,
vaan muodostetaan kysely yhdistämällä merkkijonoja tyyliin:

$query="select * from traktorit where malli='".$malli."'"
--
Juha Autero
http://www.iki.fi/jautero/
Eschew obscurity!
Timo Sirainen
2003-08-05 23:40:13 UTC
Permalink
Post by marko
Tarkoitus ei ole saada aikaan mitään ohjelmointi-threadia vaan
keskustelua siitä mitä kaikkea web-applikaation turvallisuuteen
liittyy ja mitä pitäisi ottaa huomioon.
Tämä nyt ehkä on enemmän ohjelmointiin liittyvää, mutta
hyödyllistä ehkä :)

Muut mainitsivatkin jo SQL injectionit ja cross site scripting ongelmat
jotka ovat todella yleisiä. Suurin syy on että niitä on niin helppo
saada vahingossa aikaan useimmilla kielillä.

Useimmat turvallisen ohjelmoinnin oppaat neuvovat vain tarkastamaan
käyttäjän antaman syötteen. Tuon ongelmana on se että se on
useimmiten kauhean työlästä. Edelleen useimmat tuntuu olevan sitä
mieltä että turvallinen koodaus vaatii vaivaa. Minusta tuollainen
ajattelutapa on juuri se syy miksi epäturvallista softaa tehdään niin
paljon. Älä turhaan tee asioita hankalasti ja epäturvallisesti, tee ne
helposti ja turvallisesti.

SQL injection ja XSS-ongelmat vältetään helposti tekemällä C:n
printf()-tyylisiä funktiota. Esim.:

$result = sql_exec("SELECT otsikko from taulu WHERE user = %s", user);
print xml_printf("<h1>%s</h1>\n", $result->field("otsikko"));

sql_exec() ja xml_printf() sitten itse liittävät %s:n tilalle annetun
parametrin, automaattisesti filtteröiden tai escapoiden muuttujat
turvalliseen muotoon.

Ainut ongelma onkin enää muistaa käyttää noita funktiota.

Käyttäjän syötteen tarkistaminenkin on tietty ihan kannattavaa, mutta
minusta softan pitäisi toimia turvallisesti kaikilla syötteillä. Sitä
kun ei koskaan tiedä vaikka joku sysadmin ei tykännyt jostain syötteen
rajoituksesta ja poisti sen tarkistuksen..

Jotain muita veppisoftien turvallisuuteen liittyviä asioita ovat ainakin
kaikki autentikointiin liittyvät mokat, esim. se ettei salasanan
tarkistusta pääse koskaan ohittamaan luomalla sessio käyttämällä
jotain muuta kuin pääsivua, tai että käyttää ennalta arvattavia
sessioid numeroita.
Jari Pirhonen
2003-08-07 14:43:14 UTC
Permalink
Post by marko
Tarkoitus ei ole saada aikaan mitään ohjelmointi-threadia vaan
keskustelua siitä mitä kaikkea web-applikaation turvallisuuteen liittyy
ja mitä pitäisi ottaa huomioon.
Viestistäsi sai sen kuvan, että kyseessä ei ole kovin kriittinen eikä
luottamuksellista tietoa sisältävä sovellus. Tärkeää on siis kiusanteon
estäminen ja ongelmatilanteista toipuminen?

Seuraavassa muutama ensimmäisenä mieleeni tulleita yleisiä näkökohtia ottamatta
kantaa itse koodin hyvyyteen:

- web-palvelin ja SQL-kanta erotettava palomuurilla - kanta-koneeseen pääsy
ainoastaan web-palvelimesta
- käyttäjätietokanta (mikäli tarvitaan) erilliseen laitteeseen, myös
palomuurilla erotettuna web-palvelimesta. Kompromissina esim. SQL-koneeseen
- mikäli järjestelmä pyörii yrityksen DMZ-alueella, ei sallita mitään yhteyksiä
palvelusta sisäverkkoon. Mikäli varsinainen kanta on sisäverkossa, voidaan se
replikoida DMZ-alueelle. Mikäli web-sovelluksen on pakko käyttää sisäverkossa
olevaa kantaa esim. päivitystiheyden tai tietomäärän takia, järjestelmästä tulee
monimutkaisempi ja riskialttiimpi.
- palomuurien tietoturvapolitiikka ja konfigurointi suunniteltava ja
dokumentoitava. Samoin käyttäjätunnusten hallinta. Myös kannan tunnukset
sovelluksen tarpeisiin.
- kaikki järjestelmät kovennettava ja asennukset dokumentoitava. Paitsi käyttis,
myös web-palvelin, kanta, middleware, yms.
- ennen palvelinten liittämistä Internetiin, aja niitä vasten nippu
tarkistusohjelmia: Nessus & co.
- palvelinkohtaiset IDS-ohjelmistot auttavat vahingon huomaamisessa ja
tarkistamisessa jälkikäteen
- suunnittele, miten patchit saadaan jatkossa asennettua - miten testataan
sovelluksen toimivuus ennen patchin asennusta tuotantoon
- suunnittele etukäteen toipumistaktiikka: miten selvitetään ongelman syy ja
laajuus, miten systeemi saadaan vikkelästi uudelleen pystyyn

OWASP-dokumentista saakin sitten viitteitä siitä, mitä sovelluskehittäjien on
huomioitava: SQL injection, Cross-site scripting, syötteiden tarkistus,
puskuriylivuodot, yms.

Hyvä arkkitehtuuri, huolellinen kovennus ja asennus, ajan tasalla oleva
dokumentointi ja huolellinen hallinta ovat kulmakiviä web-sovelluksessa ja
niillä voidaan minimoida sovellusongelmien riskiä. Olisi tietysti mukavaa, jos
koodaritkin huomioisivat turvanäkökohdat - valitettavasti usein koodarit
lähetetään "hakkerointikurssille" sen sijaan, että heitä koulutettaisiin
tekemään hyvää ja turvallista koodia.

Hyvä lähtökohta suunnittelussa on ajatella, että web-palvelin on "uhrilammas",
johon motivoitunut hyökkääjä voi päästä sisään. Miten minimoidaan vahingot
web-palvelimeen tunkeutuneelta hyökkääjältä eli suojataan kanta, käyttäjätiedot,
sisäverkko,...?

Jari

--

Jari Pirhonen

"Don't wrestle with pigs. You get muddy, sweaty, tired, mad, covered with crap,
and when you're done the pig loved it anyway"
marko
2003-08-07 18:53:41 UTC
Permalink
On Thu, 07 Aug 2003 17:43:14 +0300
Post by Jari Pirhonen
luottamuksellista tietoa sisältävä sovellus. Tärkeää on siis
kiusanteon estäminen ja ongelmatilanteista toipuminen?
Aivan. Kyse oli vain esimerkistä, ei oikeasta saitista. Tosin en
ihmettele jos jossain on tuollainen porakone-vertailu kanta olemassa :)
Post by Jari Pirhonen
- web-palvelin ja SQL-kanta erotettava palomuurilla - kanta-koneeseen
Jos ei ole tarpeeksi fyrkkaa, niin silloinhan voisi käyttää
käyttöjärjestelmän omaa filtteröintiä hyväksi. Muutenkin tuota
mahdollisuutta voisi varmasti hyödyntää enemmänkin.
Post by Jari Pirhonen
SQL-koneeseen- mikäli järjestelmä pyörii yrityksen DMZ-alueella, ei
sallita mitään yhteyksiä palvelusta sisäverkkoon. Mikäli varsinainen
Ei pidä myöskään sallia ulospäin DMZ:sta. Jos kuitenkin tarvitaan esim
DNS-kyselyitä varten, niin silloin se rajataan tarkasti mihin
palvelimiin saa ottaa yhteyttä.
Post by Jari Pirhonen
käyttäjätunnusten hallinta. Myös kannan tunnukset sovelluksen
Antamalla vain tarvittavat oikeudet käyttäjälle voidaan vähentää riskiä,
eli jos tarve on päästä lukemaan vain yhtä taulua, niin mitä järkeä on
antaa siihen kirjoitus/päivitys/deletointi oikeuksia? Stored
Procedureilla voidaan myös vaikuttaa turvallisuuteen.

Tässä esimerkki-saitissa tosin täytyy antaa luku-/kirjoitus-oikeudet
toiseen tauluun joka toimii "forumina".
Post by Jari Pirhonen
tarpeisiin.- kaikki järjestelmät kovennettava ja asennukset
dokumentoitava. Paitsi käyttis, myös web-palvelin, kanta, middleware,
Jos mahdollisuus on chrootata esim web-palvelin ja applikaatio saadaan
silti toimimaan, niin tämä varmasti olisi ihan järkevää. Least Privilege
ajattelu on ihan hyväksi. Tämä tekee hyökkääjän tehtävästä vaikeamman.
Post by Jari Pirhonen
- suunnittele etukäteen toipumistaktiikka: miten selvitetään ongelman
syy ja laajuus, miten systeemi saadaan vikkelästi uudelleen pystyyn
Tämä on varmaan yksi sellainen jota monikaan ei juuri ajattele. Mitä jos
tapahtuu tietomurto, miten pitää toimia? Osataanko toimia oikein,
saadaanko incident response & forensics tehtyä mallikkaasti jos pitää
mennä oikeuteen jne. Sen lisäksi pitäisi vielä tietää miten päästään
jatkamaan mahdollisimman nopeasti ettei bisnes kärsi.
Post by Jari Pirhonen
sovelluskehittäjien on huomioitava: SQL injection, Cross-site
scripting, syötteiden tarkistus, puskuriylivuodot, yms.
Näitä mä lähinnä hain kun tuon postauksen pistin ilmoille. Tuo mitä
ylempänä käsittelit, on ihan hyvää asiaa, mutta ajattelin nimenomaan sen
web-applikaation näkökulmasta.. tai oikeastaan hyökkääjän näkökulmasta,
sillä jos patchit ovat OK ja muuten homma on hoidettu mallikkaasti, niin
ainoa mahdollisuus on odottaa jotain 0-day exploittia tai yrittää rikkoa
itse web-sovellus.

Tietoturva on kuin sipuli, koostuen eri tasoista, jokaisella tasolla
voidaan tehdä jotain josta on hyötyä.

-m-
--
- Liquid Information - http://www.liquidinfo.net
- E-mail: Remove NOS_PAM if present in address (Usenet)
- PGP: http://www.liquidinfo.net/about.html
--
Jari Pirhonen
2003-08-08 08:45:52 UTC
Permalink
Post by marko
Post by Jari Pirhonen
sovelluskehittäjien on huomioitava: SQL injection, Cross-site
scripting, syötteiden tarkistus, puskuriylivuodot, yms.
Näitä mä lähinnä hain kun tuon postauksen pistin ilmoille. Tuo mitä
ylempänä käsittelit, on ihan hyvää asiaa, mutta ajattelin nimenomaan sen
web-applikaation näkökulmasta.. tai oikeastaan hyökkääjän näkökulmasta,
sillä jos patchit ovat OK ja muuten homma on hoidettu mallikkaasti, niin
ainoa mahdollisuus on odottaa jotain 0-day exploittia tai yrittää rikkoa
itse web-sovellus.
Nuo em. sovellusongelmat ovat lähinnä huonoa, virheellistä koodia ja niiden
löytämiseen on olemassa myös testityökaluja. Vaarallisempaa on, jos
sovelluksessa on perustavaa laatua olevia, turvallisuutta heikentäviä
suunnitteluvirheitä tai virheellisiä olettamuksia käyttötavasta ja ympäristöstä.
Toki virheitä etsivän on black-box testauksella helpompi löytää noita koodi-
kuin suunnitteluvirheitä.

Sovelluskehityksen ongelma on, että täytyy luottaa liian moneen annettuun
komponenttiin: käyttis, tietokanta, application server, APIt, jne. Siksi
korostaisin turva-arkkitehtuurisuunnittelun tärkeyttä. Web-palvelimesta löytyy
kuitenkin joskus joku reikä - se ei kuitenkaan saa vaarantaa koko järjestelmää
eikä muita palveluita.

Lukemisen arvoinen paperi on myös "Best Practices for Secure Development",
http://members.rogers.com/razvan.peteanu/best_prac_for_sec_dev4.pdf


Jari
--
Jari Pirhonen

"Don't wrestle with pigs. You get muddy, sweaty, tired, mad, covered with crap,
and when you're done the pig loved it anyway"
marko
2003-08-13 06:23:49 UTC
Permalink
On Fri, 08 Aug 2003 11:45:52 +0300
Post by Jari Pirhonen
Nuo em. sovellusongelmat ovat lähinnä huonoa, virheellistä koodia ja
niiden löytämiseen on olemassa myös testityökaluja. Vaarallisempaa on,
jos sovelluksessa on perustavaa laatua olevia, turvallisuutta
heikentäviä suunnitteluvirheitä tai virheellisiä olettamuksia
Eivät ne testi-työkalutkaan varmaan kaikkea löydä. Kyse voi olla
logiikka-ongelmasta tai jostain muusta (esim huono sessio-hallinta
tjsp).

Sallinet kuitenkin olla hieman eri mieltä tuosta vaarallisuudesta:
Mielestäni se vaaraa piilee nimenomaan siinä käyttäjälle tarjotussa
interfacessa, eli web-sovelluksessa. Tämä juuri sen takia että se on
monesti ainoa mahdollisuus hyökkääjälle päästä sisään.

Mitä monimutkaisempi sovellus, sitä suurempi riski että hyökkääjä löytää
jonkin tavan exploitata sitä. Totta, allaolevat komponentit vaikuttavat
tietoturvaan tässä tapauksessa, mutta pääasiallinen vastuu siitä, että
asiat tehdään oikein on sovelluksella. Vaikka sulla olisi kuinka hienot
systeemit alla, niin ongelma itse sovelluksen koodissa, esimerkiksi
heikko input validation tietokanta-kyselyn kohdalla, altistaa
tietokannan hyökkäykselle.

Näin ainakin itse näen asian.

-m-
--
- Liquid Information - http://www.liquidinfo.net
- E-mail: Remove NOS_PAM if present in address (Usenet)
- PGP: http://www.liquidinfo.net/about.html
--
Jari Pirhonen
2003-08-13 10:59:18 UTC
Permalink
Post by marko
On Fri, 08 Aug 2003 11:45:52 +0300
Post by Jari Pirhonen
Nuo em. sovellusongelmat ovat lähinnä huonoa, virheellistä koodia ja
niiden löytämiseen on olemassa myös testityökaluja. Vaarallisempaa on,
jos sovelluksessa on perustavaa laatua olevia, turvallisuutta
heikentäviä suunnitteluvirheitä tai virheellisiä olettamuksia
Eivät ne testi-työkalutkaan varmaan kaikkea löydä. Kyse voi olla
logiikka-ongelmasta tai jostain muusta (esim huono sessio-hallinta
tjsp).
Nämä ovatkin juuri niitä tarkoittamiani suunnitteluvirheitä. Esim.
istunnonhallinta voi olla loistavasti speksin mukaan koodattu, mutta jos speksi
on jo pielessä, niin hyväkään koodi ei auta...
Post by marko
Mielestäni se vaaraa piilee nimenomaan siinä käyttäjälle tarjotussa
interfacessa, eli web-sovelluksessa. Tämä juuri sen takia että se on
monesti ainoa mahdollisuus hyökkääjälle päästä sisään.
Mitä monimutkaisempi sovellus, sitä suurempi riski että hyökkääjä löytää
jonkin tavan exploitata sitä. Totta, allaolevat komponentit vaikuttavat
tietoturvaan tässä tapauksessa, mutta pääasiallinen vastuu siitä, että
asiat tehdään oikein on sovelluksella. Vaikka sulla olisi kuinka hienot
systeemit alla, niin ongelma itse sovelluksen koodissa, esimerkiksi
heikko input validation tietokanta-kyselyn kohdalla, altistaa
tietokannan hyökkäykselle.
Näin ainakin itse näen asian.
Vaarallisuudella tarkoitin oikeastaan sitä, että logiikavirhe tai huonosti
suunniteltu softa voi avata isomman, vaikeammin jäljitettävän aukon sovellukseen
kuin ohjelmointivirhe.

Ohjelmointivirheet ovat toki vaarallisempia siinä mielessä, että niiden haeskelu
ulkopuolisen toimesta voi olla helpompaa.

Jari
--
Jari Pirhonen

"Don't wrestle with pigs. You get muddy, sweaty, tired, mad, covered with crap,
and when you're done the pig loved it anyway"
Continue reading on narkive:
Loading...