Mikä hitto siinä sql syötteen sanitoimisessa oikein on niin vaikeaa?

Onko web-palvelujen koodaajat oikeasti niin laiskoja, etteivät jaksa POST/GET:ssä tulevia arvoja tarkastaa vaikka edes sillä valmiilla escape-funktiolla, jollainen löytyy jokaisesta web-kielestä?

Eipä voi käsittää kuka ylipäätään jaksaa tehdä sivuston, jolla ei ole joko itsetehtyä (turhaa työtä) tai valmista yleistä sql rajapintaa joka pitää huolen siitä, ettei kyselyissä ole ko. "sql-injection" hyökkäystä. Tosin siinä vaiheessa, jos itsetehdyssä rajapinnassakaan ei ole vaivauduttu lisäämään yhtä koodiriviä niin alkaa olemaan www-ohjelmointi hanskassa.

Eipä voi käsittää kuka ylipäätään jaksaa tehdä sivuston, jolla ei ole joko itsetehtyä (turhaa työtä) tai valmista yleistä sql rajapintaa joka pitää huolen siitä, ettei kyselyissä ole ko. "sql-injection" hyökkäystä.

Ei sinänsä mitään valmiita sql-rajapintoja vastaan, mutta eivät nekään mikään tietoturvan tae ole. Yhden koodaajan laiskuus saattaa rajapinnoissakin lähteä kiertämään ja kohta kaikista samaa rajapintaa käyttävistä softista löytyy reikä.

Huono neuvo, arvaas johtaako tämmöinen käytäntö siihen että escapetetaan integeritkin ja ajatellaan että sitten ollaan turvassa? Vaan hupsista, escape ei auta kun oltiin jo valmiiksi niiden hipsujen ulkopuolella! Castaisivat edes intiksi sen niin että siellä ei voi olla muuta kuin numeroita, joka tuntuu olevan aika yleinen tapa...

Toinen hauskuushan tulee sitten siinä että sql:ää varten pitää sanitoida yhdellä tapaa ja html:ää varten erilailla. Osa koodaajista menee vipuun ja escapettaa toisellatapaa molempiin tarkoituksiin, jolloin tuloksena on joko XSS-reikä tai SQL-injektio.

Tuntuisi olevan enemmän kyse huolimattomuudesta ja ongelmista koodauskäytännössä kuin laiskuudesta. Funktiota toteutettaessa saatetaan ajatella että data tulee ohjelman sisältä ja sisältää vain validimuotoista dataa, toisessa paikkaa funktiota sitten käytetään ja ollaan unohdettu missä se data piti validoida.

Suuri osa koodaajista ei myöskään miellä bugiksi sitä että funktio ei tarkista onko sille annettu parametrit oikein, vaan ajatellaan että jos siinä on virhe niin bugi onkin koodissa jossa funktiota kutsutaan. Tuloksena on soppa jossa tietoturva-aukolta olisi voitu välttyä, jos vain koodin sisäiset vastuut olisi määritetty paremmin.

PS. Sampo pankin XSS-aukot johtuivat osaltaan tuommoisesta koodin sisäisestä vastuuvirheestä. Muuttujia käytettäessä niitä ei validoitu, eikä taideta validoida vieläkään. Sensijaan lisättiin satunnaisia heikkoja tarkistuksia sinne missä muuttujat otetaan osoiteriviltä talteen, ja itse bugit ovat vieläkin siellä.

Nämä sql-injection -hyökkäykset näyttävät olevan erityisesti php:llä tehtyjen sivustojen ongelma. Esim. ASP.NET:ssä moiset hyökkäykset ovat mahdottomia jos kehittäjällä on vähänkään älyä. Niissä käytetään nimittäin parametrisoitavia sql-lausekkeita (vanha tapa) tai sitten suoraan linq-tekniikkaa (vrt. muut orm-välineet). Tuo php taitaa olla yhä yksi niistä ainoista joissa näkee jatkuvasti noita "select * from foo where bar = " + value tyylisiä viritelmiä.