Tänä päivänä web -tietoturva on suorastaan järkyttävän heikolla tasolla !
Tässä yksi esimerkki, mitä rikolliset krakkerit tunkevat web -sivulle, jos web -palvelimessa on mikä tahansa sellainen tietoturvareikä, josta asiattomat saavat tungettua omaa dataansa web -sivulle:
Mielenkiintoista!
Tosin, eikö tuo esimerkki jättäisi näkyville punaisen rastin (tämänhän moni selain näyttää, kun sivulle yritetään linkata kelvoton kuva, eli kuvaa ei ole olemassa tai tiedosto ei ole korrektia kuvaformaattia) ?
Tutkiessani itse tietoturva-asioita "nippelitasolla", selvisi, että itseasiassa web -teknologiassa on aivan liikaa escape -mekanismeja.
Tämä on omiaan aiheuttamaan tietoturvareikiä. Jos web -koodaaja osaakin varoa muutamaa yleisintä escapea, ja koodata niiden väärinkäytölle esto, niin riittää, että koodissa on jätetty ottamatta huomioon yksikin harvinaisempi escape - ja hyökkääjällä on täydet valtuudet tehdä, mitä haluaa!
Ja noita escape -mekanismeja kun on vielä niin monella tasolla.
1. esimerkiksi html -escapet:
http://www.theukwebdesigncompany.com/articles/entity-escape-characters.php
Tuo sivu väittää "HTML Escape Characters: Complete List"
Mutta onko lista siltikään täysin kattava - vai onko muitakin ?
2. URL -escapet:
http://www.december.com/html/spec/esccodes.html
Tuo sivu taas viittaa ASCII -koodeihin ?
Onko URLien merkkivalikoima todella rajoitettu vain ascii -merkkeihin (0..127) ?
Lisäksi, tuo sivu unohtaa tämän (hyvin yleinen):
= välilyönti
Löytyyköhän noista koodeista jostakin todella kattavaa listaa ?
Oikeasti turvallisen palvelimenhan pitäisi syötettä käsitellessään ottaa huomioon kaikki mahdolliset koodaukset - muuten seurauksena on se, että jos yksikin koodaustapa jää ottamatta huomioon, se tarjoaa rikollisille krakkereille helpon pääsyn asiattomiin muutoksiin tietojärjestelmään ja lisämahdollisuuden muihin hyökkäyksiin - joko palvelinta tai sen käyttäjiä vastaan.
web -tietoturva
5
414
Vastaukset
- keksa1
se että koodaaja ei validoi tai puhdista käyttäjän antamaa syötettä oli sen sitten lomakkeessa, urlissa, requestin headereissa tai cookiessa.
yleensä ei tarvitse kaikkia mahdollisia enkoodaustapoja ottaa huomioon. Jos annettava syöte näytetään webisivulla, esimerkiksi lomakkeella kysytään käyttäjän nimi, niin enkoodataan se niin ettei siinä ole merkkejä joilla on erikoismerkitys HTML-kielessä tai selaimelle muutenkaan.
Siihen riittää esim. PHP:n htmlspecialchars().
Nyt jos nimeksi yrittää antaa < script> alert('hax0r') < /script> niin tuo PHP:n metodi muokkaa tuosta harmittoman version.
Toinen tapa voisi olla niin kutsuttu "whitelist" eli annettuja merkkejä verrataan sallittujen merkkien listaa vasten. Jos siellä on joku kielletty merkki, niin virheilmoitus ja näytetään lomake uusiksi.
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
Muutenkin webbikoodarien kannattais mennä OWASPin top 10 lista läpi, että onko omassa sovelluksessa tullut tehtyä mokia.
http://www.owasp.org/index.php/Top_10_2007- sisäpiiririkos?
Jos käyttäjän syöttämät tiedot menevät tietokantaan niin kannattaa myös ajatella että mitähän tapahtuu jos käyttäjä kieli poskesa kirjoittaa nimekseen vaikkapa:
NIKO-PETTERI; DELETE FROM ASIAKAS_TIEDOT
Vaarana on että SQL lauseessa
INSERT INTO TAULU (NIMI) VALUES ($nimi)
Vaarana on että käyttäjän antama puolipiste lopettaa SQL-lauseen ja kannassa suoritetaan sitä seuraava lause.
Ehkä siinä täytyy hiukan tietää että osaa tällaista jäynää tehdä, mutta riittävän moni osaa. - ..
sisäpiiririkos? kirjoitti:
Jos käyttäjän syöttämät tiedot menevät tietokantaan niin kannattaa myös ajatella että mitähän tapahtuu jos käyttäjä kieli poskesa kirjoittaa nimekseen vaikkapa:
NIKO-PETTERI; DELETE FROM ASIAKAS_TIEDOT
Vaarana on että SQL lauseessa
INSERT INTO TAULU (NIMI) VALUES ($nimi)
Vaarana on että käyttäjän antama puolipiste lopettaa SQL-lauseen ja kannassa suoritetaan sitä seuraava lause.
Ehkä siinä täytyy hiukan tietää että osaa tällaista jäynää tehdä, mutta riittävän moni osaa.NIKO PETTERI'); DROP TABLE ASIAKAS_TIEDOT; --
Huomaa lopussa oleva kommenttimerkki '--', joka estää mahdolliset SQL-virheet. - keksa1
.. kirjoitti:
NIKO PETTERI'); DROP TABLE ASIAKAS_TIEDOT; --
Huomaa lopussa oleva kommenttimerkki '--', joka estää mahdolliset SQL-virheet.että jos sql-lause kaipaa merkkijonoa, niin käyttäjän syöte otetaan merkkijonona eikä mahdollisesti useana komentona.
http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html
http://php.net/manual/en/pdo.prepared-statements.php
Noilla kun tekee sen SQL-koodin, niin nimeksi menee sitten NIKO PETTERI'); DROP TABLE ASIAKAS_TIEDOT; --
eikä mitään tauluja tuhota. tietenkin vois hiukka tehdä validointia ennen tuota, että nimessä on annettuna vain sallittuja merkkejä. Ei taida Suomessa olla yhtään Pekka;-Virtasta
PS. ensimmäiselle kirjoittajalle tiedoksi, että ei kaikkiea mahdollisia enkoodauksia tarvitse ottaa huomioon. Ne vain joilla on merkitystä. Ei jonkun mystisen enkoodauksen puuttuminen sitä tarkoita, että sillä voi sittten heti murtautua johonkin.
Jos syötettyä tietoa näytetään html-sivuilla ja osana sql-kyselyjä, niin silloin riittää sen varmistaminen, että noihin kahteen liittyvät erikoismerkit ei mene läpi.
- ogma
Kuten tässä jo mainittiinkin, ei merkit sinällään ole paha vaan se, että merkit siirretään komentoon sellaisenaan. Esim. Unix-palvelimella "&rm -rf /" voi aiheuttaa ongelmia.
Tuo "HTML Escape Characters" lista ei todellakaan ole täydellinen. Se näyttäisi Unicode-listan länsi-eurooppalaisen merkistön osalta. Siitä puuttuu noin 65000 muuta merkkiä. Tämän lisäksi kokonaislukuavaruudessa on noin ääretön muuta lukua, joka voidaan tulkita merkiksi, jossain merkistön koodaustavassa.
Jälkimmäiselle listalle löytyy selitys URI:n "standardissa" RFC3986:sta. Se kertoo kuinka URI:ssa pitää tietyt hankalat merkit koodata "normaaleiksi" merkeiksi.
Käytännössä molemmat listat kuvaavat eri aihealueen lähestymistapaa samaan hankalaan aiheeseen eli merkistöjen koodaukseen.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Ootko nainen noin mustis musta
Onhan se toki imartelevaa kun olet kaunis ja kaikkea muutakin, mutta ehkä vähän kummallista, kun ei varsinaisesti olla t734416- 332511
- 402324
Ajattelen sinua tänäkin iltana
Olet huippuihana❤️ Ajattelen sinua jatkuvasti. Toivottavasti tapaamme pian. En malttaisi odottaa, mutta odotan kuitenkin211815Kauan säkin jaksoit
Minun perässä juosta. Kunnes pahoitit mielen. Kuinka monta anteeksipyyntöä olet vailla? 🧐401672Miksi kaipaat
Ja olet elämässäni vielä kaiken tämän jälkeen? Eikö kaikki ole jo selvää välillämme?251552- 811536
- 1491346
Mietin tässä T....
Oletko jo kesälomalla.?Keli on ihanaa, ja sinä nautit veneilystä.... Edelleen käyt mielessä.... En ole unohtanut sinua..221243Miehelle...
Oliko kaikki mökötus sen arvoista? Ei mukavalta tuntunut, kun aloit hiljaisesti osoittaa mieltä ja kohtelit välinpitämät901145