Miksi kannattaa tehdä käyttöliittymästä välitettyjen tietojen virheentarkistus palvelimella, eikös se aiheuta ylimääräistä liikennettä verkon yli, kun palvelimessa oleva softa huomaa että tieto on väärässä muodossa ja lähettää siitä ilmoituksen verkon yli käyttäjälle ja käyttäjä korjaa?
Pahimmassa tapauksessa jos on iso lomake korjaamisia tehdään moneen kertaan.
Eikö kannattaisi tarkistaa selainlomakkeessa scriptissä mielummin?
Pahimmassa tapauksessa jos on iso lomake korjaamisia tehdään moneen kertaan.
Eikö kannattaisi tarkistaa selainlomakkeessa scriptissä mielummin?
Vastaukset 5
Vanhimmat
Molemmat tarkistus -muodot kannattaa ottaa käyttöön.
Selainpäässä JavaScript tarkistaa tiedot näppärästi ja nopeasti.
Tiedot kannattaa kuitenkin tarkistaa myös palvelinpäässä esim. ennen tietokantaan viemistä. Tämä esimerkiksi siksi, että jos surffaaja on näpäyttänyt selaimestaan JavaScriptin pois päältä niin virheentarkistukset jää kokonaan tekemättä.
Osa tiedoistahan vaatii pakosti palvelinpään tarkistusta, esim. käyttäjänimen ja salasanan oikeintarkistus kannasta. Mutta JavaScriptillä kannattaa tietty tarkistaa ennen sitä, että käyttäjä on ylipäänsä syöttäny tarpeeks pitkät tiedot kenttiin ennen napin painallusta.
Olet oikeessa, ihan kaikkea ei käyttöliittymätasolla pysty tekemään, mutta kannattaa pyrkiä tekemään siinä mahdollisimman paljon jolloin turha verkkoliikenne jää vähemmälle.
kannattaa tehdä sellaisia tarkistuksia, jotka nopeuttavat käyttöä. Esimerkiksi ei lähetetä lomaketta, jonka pakollisia kenttiä ei ole täytetty.
Palvelinpäässä taas tarkistetaan, että kenttiin ei ole syötetty koodia/skriptiä. Jos viet tiedot käsittelemättä vaikka tietokantaan, niin voi sattua kauheita. Pistää tekstikenttään vaikka /gDELETE * FROM *
niin MySQL poistaa kaikki taulun kannat.
Jos vaikka lukee jonkun jättämän viestin ja tämä viesti onkin skriptiä, niin käyttäjä ehkä ohjataan toiselle webbisivulle ja skripti varastaa sinulta session selaimesta. Sen jälkeen ilkeä rosmo pääsee sinun sessiollasi alkuperäiselle saitille.
Selaimen tarkistuksiin ei saa ikinä luottaa, koska rosmo voi vain esittä selainta ja itse asiassa vastapää onkin rosmon oma ohjelma, joka vain kertoo olevansa Explorer ja javascript päällä.
Tai rosmo kirjautuu vaikka tilauspalveluun ja tunnistautuu vaikka jollain avainkoodilla tms. Sitten hänelle tulee tilauslomake, jossa on vaikka hidden-kentässä tilaajanumero. No hän voi napata requestin ja muuttaa lähtevään lomakkeeseen sen tilalle mitä haluaa.
Palvelinpäässä taas tarkistetaan, että kenttiin ei ole syötetty koodia/skriptiä. Jos viet tiedot käsittelemättä vaikka tietokantaan, niin voi sattua kauheita. Pistää tekstikenttään vaikka /gDELETE * FROM *
niin MySQL poistaa kaikki taulun kannat.
________________________________________
Ei kai sentään suoraan DELETE-oikeutta anneta
verkon yli kantaan??
Miettisin lähinnä päivitysoikeuden antamista näkymään ja sitäkin tarkasti harkiten.
Voisi olla esim. erillinen kanta johon kerättäisiin tapahtumat verkosta ja sitten eräajona tarkistusten jälkeen tehtäisiin päivityksiä, ettei tulisi isoja vahinkoja.
Esim. DELETE:n voisi korvata poistomerkinnällä.
Jos vaikka lukee jonkun jättämän viestin ja tämä viesti onkin skriptiä, niin käyttäjä ehkä ohjataan toiselle webbisivulle ja skripti varastaa sinulta session selaimesta. Sen jälkeen ilkeä rosmo pääsee sinun sessiollasi alkuperäiselle saitille.
Selaimen tarkistuksiin ei saa ikinä luottaa, koska rosmo voi vain esittä selainta ja itse asiassa vastapää onkin rosmon oma ohjelma, joka vain kertoo olevansa Explorer ja javascript päällä.
________________________________________________
Eikö kannattaisi toimia suojatussa yhteydessä jos
naamioitumisesta voi koitua isojakin vahinkoja?
_________________________________________________
Tai rosmo kirjautuu vaikka tilauspalveluun ja tunnistautuu vaikka jollain avainkoodilla tms. Sitten hänelle tulee tilauslomake, jossa on vaikka hidden-kentässä tilaajanumero. No hän voi napata requestin ja muuttaa lähtevään lomakkeeseen sen tilalle mitä haluaa.
_________________________________________________
Tässä kohtaa voisi auttaa salasanat ja digitaaliset allekirjoitukset, jotka tehdään tilattaessa. Eli varmistetaan että tilaaja on juuri se joka se väittää olevansa.
"Ei kai sentään suoraan DELETE-oikeutta anneta
verkon yli kantaan??
Miettisin lähinnä päivitysoikeuden antamista näkymään ja sitäkin tarkasti harkiten.
Voisi olla esim. erillinen kanta johon kerättäisiin tapahtumat verkosta ja sitten eräajona tarkistusten jälkeen tehtäisiin päivityksiä, ettei tulisi isoja vahinkoja.
Esim. DELETE:n voisi korvata poistomerkinnällä. "
No kun se se kantaa käyttävä skripti toimii rootin tai ainakin kantaa päivittävän oikeuksilla ja eihän se verkon yli tapahdu, kun skripti on samalla palvelimella.
Eli lomakkeessa on vaikka Nimi: kenttä ja normaalisti käyttäjä syöttää siihen että Paavo. No rosmo syöttääkin Paa\gDELETE * FROM *
php sitten palvelimessa alkaa pistää sitä kentän tietoa kantaan. MySQL huomaa tietyn erikoismerkin joka tarkoittaa, että "lopeta heti mitä oet tekemässä ja toteuta seuraava käsky". Tietty skriptille voi antaa vaan jonkun päivitysoikeuden, mutta eikö ois helpompi poistaa erikoismerkit syötteestä?
"Eikö kannattaisi toimia suojatussa yhteydessä jos
naamioitumisesta voi koitua isojakin vahinkoja?"
Ei paljo auta suojatut yhteydet, jos siihen väliin on päässyt jo joku. Yhteys on kyllä salattu sinä -> rosmo -> palvelu, mutta rosmo salaa sitä sinuun päin ja taas palveluun päin, eli rosmolle yhteys ei oikeasti ole salattu.
Sitten kun kaikki kirjautumiset on suoritettu palveluun päin, niin kaappaa session ja lähettää jonkun paketin käyttäjän Exploreriin joka kaataa sen.
Publickey/Privatekey tyyppisten sertifikaattien käyttäminen salattuun yhteyteen on murtovarma juttu, jos sertifikaatin oikeellisuus käydään varmistamassa joltain VeriSignilta. Sen jälkeen on kyse taas käyttäjän tarkkaavaisuudesta.
Jos IE heittää ruudulle ilmoituksen sertifikaatista ja siinä on muuta kuin 3 vihreetä pallukkaa, niin välissä saattaa olla jo rosmo tai sitten ei oikeesti saada yhteyttä sertifikaatin varmistajaan.
Tää menee nyt hiukan kauas siitä alkuperäisestä pointista, että miksi selaimessa tehtäviin tarkistuksiin ei voi luottaa :)