Olen opiskellut verkkopohjaisten palvelujen tuottamista ammattikoulussa ja nyt olisi tarkoitus soveltaa taitoja käytännössä omassa harrasteprojektissa. Ongelmallisena tilanteessani vaikuttaa se, että ammattikoulussa opiskelimme vain kuinka ohjelmoidaan pieniä yleensä staattisia sivustoja, joilla sattui olemaan yksi tai kaksi lomaketta, joita sitten käsiteltiin php:lla. Kuitenkin tutustuimme php:hen tätä laajemmin, eli voin sanoa että omankin kiinnostuksen myötä osaan kyseisen ohjelmointikielen perusteet ja toimintaperiaatteet hyvin.
Olen itse tutustunut nyt MVC ja HMVC malleihin toteutuksesta ja ne vaikuttaisivat olevan järkeviä tulevan projektini toteuttamisen kannalta, sillä ne antavat tuntuman, kuinka luodaan ylläpidettävää koodia. Eli jos vain mahdollista, niin tiedättekö hyviä sivustoja/kirjallisuutta, joiden avulla voisin paneutua enemmän MVC ja HMVC malleihin? En kuitenkaan ole vielä täysin tarketunut MVC malliin, niin jos tiedätte jonkun "paremman" ratkaisun toteuttaa tietokantapohjainen verkkopalvelu niin kertokaa. Tärkeintä on se, että ohjelman koodi voidaan modularisoida helposti ja en etsi valmista mallia, vaan teoriaa jota voin lähteä soveltamaan käyttötarpeisiini.
Toinen ongelmakohtani suunnittelussa on se, että kuinka toteuttaa tietoturvallista ja muutenkin sellaista php-koodia, joka ei sisällä kriittisiä aukkoja. Koulutukseni pohjalta olemme käyneet läpi sen, että tärkeimmässä roolissa on käyttäjien syötteen tarkistus aina. Onko käyttäjien syötteen tarkistuksen lisäksi otettava vielä huomioon muita tietoturvaan liittyviä asioita?
Tässä on jo näitä pyyntöjä tullut, mutta jos vielä jatketaan hieman, onko verkkopuolella olemassa dokumentointikäytäntöjä taustajärjestelmille? Itselleni on tuttua suunnitelman dokumentointi, eli mitä näkyy käyttäjälle ja miten minkäkin asian tulisi toimia. Lisäksi olen tehnyt tietokantasuunnittelua ja dokumentaatiota kyseisestä asiasta.
Jos tulee kysyttävää niin vastailen mielelläni ja toivon, että keskustelu pysyy asiallisena.
Olitko ajatellut käyttää valmista ohjelmistokehystä vai tehdä kaiken itse?
Tekemällä itse oppii paljon, mutta siinä keksii kyllä pyörän uudelleen ja uudelleen.
Jesse Korhonen kirjoitti:
Toinen ongelmakohtani suunnittelussa on se, että kuinka toteuttaa tietoturvallista ja muutenkin sellaista php-koodia, joka ei sisällä kriittisiä aukkoja. Koulutukseni pohjalta olemme käyneet läpi sen, että tärkeimmässä roolissa on käyttäjien syötteen tarkistus aina. Onko käyttäjien syötteen tarkistuksen lisäksi otettava vielä huomioon muita tietoturvaan liittyviä asioita?
Selvästi yleisimmät ongelmat ovat SQL-injektiot ja XSS-aukot. Kummankaan kohdalla käyttäjän syötettä ei pidä yrittää tarkistaa, vaan se pitää käsitellä. Tarkistaminen tarkoittaisi, että syötettä katsotaan ja väärä syöte jotenkin hylätään, mikä on toki hyvä tehdä joskus muista syistä (esim. salasanan tarkistus, sähköpostiosoitteen muodon tarkistus) mutta ei sovi esimerkiksi foorumin viesteihin mitenkään. Käsittely taas tarkoittaa, että syöte muutetaan sellaiseen muotoon, ettei siitä voi olla haittaa.
SQL-injektiot saa estettyä, kun käyttää parametrisoituja kyselyitä, esimerkiksi PDO-rajapintaa, ja syöttää sille kaikki käyttäjältä tulevat muuttujat oikein (PDO:ssa execute-metodille). Jos jostain syystä ei halua käyttää näitä nykyaikaisia rajapintoja vaan esimerkiksi käytöstä poistunutta mysql-rajapintaa, jokainen muuttuja pitää a) laittaa lainausmerkkeihin ja escapettaa tai b) pakottaa luvuksi esimerkiksi intval-funktiolla.
XSS-aukkoja ei tule, kun ajaa kaiken käyttäjältä tai tietokannasta tulevan tiedon htmlspecialchars-funktion läpi ennen tulostusta ja käyttää HTML-koodissa attribuuttien arvojen ympärillä lainausmerkkejä (") eikä hipsuja ('), nimittäin mainittu funktio muuttaa vain lainausmerkit turvallisiksi, ellei siltä erikseen pyydä myös hipsujen muuttamista. Lisäksi linkeistä pitää hylätä javascript-skeema ja data-skeema, jos tiedon tyyppi ei ole tunnettu. URLien osat kuuluu enkoodata funktiolla urlencode (GET-parametrit) tai rawurlencode (polun osat). JavaScriptin sekaan syötettä ei tietenkään pidä laittaa kuin datana eli json_encode-funktiolla käsiteltynä.
Kolmas tärkeä asia on oikeuksien tarkistus. Pari kertaa on täälläkin nähty jonkun aloittelijan sivut, joilla ylläpitäjän työkaluja ei ole suojattu, kunhan vain arvaa niiden osoitteen. Linkin tai valintalaatikon piilottaminen ei siis ole minkäänlainen suojaus. Jos johonkin tarvitaan erityisiä oikeuksia, ne pitää tarkistaa uudestaan jokaisella asiaan liittyvällä sivunlatauksella.
Muista myös oikea salasanojen käsittely; tätä ei ehkä kaikissa kouluissa tiedetä opettaa järkevästi. Vielä yksi vaaran paikka on tiedostojen lähettely, jossa ei myöskään voi luottaa käyttäjään vaan tiedostolle pitää laittaa tiedostolle yksilöllinen nimi (esimerkiksi järjestysnumero) ja turvallinen pääte.
Näillä pääsetkin tietoturvassa melko pitkälle. Mielestäni tätä perustason tietoturvaa ei tarvitse lainkaan miettiä, vaan muutamalla yksinkertaisella käytännöllä kaikki sujuu hyvin. Vaikeammat asiat ovat sitten vaikeampia.
Harrasteprojektin kyseessä ollessa haluan lähteä aivan alusta asti liikkeelle ja oppia mitä toimii sivuston pohjallakin. Lisäksi edellämainitsemassani viestissä kyselin lähdemateriaalia juuri teoriaan, sillä haluan myös harjotella/oppia kuinka toteuttaa ohjelmaa teorian perusteella ilman valmista koodipohjaa.
Olen toteuttanut muutaman sivuston käyttäen CodeIgniter ohjelmistokehystä, joten tiedän kuinka valmis ohjelmistokehys nopeuttaa toteuttamista ja tekee joitain asioita valmiiksi puolestani.
Metabolix kirjoitti:
XSS-aukkoja ei tule, kun ajaa kaiken käyttäjältä tai tietokannasta tulevan tiedon htmlspecialchars-funktion läpi ennen tulostusta ja käyttää HTML-koodissa attribuuttien arvojen ympärillä lainausmerkkejä (") etkä hipsuja ('), nimittäin mainittu funktio muuttaa vain lainausmerkit turvallisiksi, ellei siltä erikseen pyydä myös hipsujen muuttamista.
Kyseinen tieto oli itselleni täysin uusi, vaikkakin jo aikaisemmin olen ollut tietoinen XSS aukoista. Kiitoksia myös aikaisemman käsitevirheeni korjaamisesta.
Salasanojen käsittely on sentään opetettu koulussa hyvin ja tullut lisäksi esiin monissa eri paikoissa. Lisäksi koulussamme on opetettu PDO rajapinnan käyttöä ja antamasi tieto vahvisti omaa ajatustani sen turvallisuudesta.
Jos kiinnostaa tietää, että mitä frameworkkien sisällä tapahtuu, niin kannattaa tutustua ensinnäkin valmiiden frameworkkien koodiin ja sitten kannattaa tutustua suunnittelumalleihin (eng. design patterns). MVC-mallihan perustuu lähtökohtaisesti nk. Observer-suunnittelumalliin, mutta frameworkeissä käytetään yleensä lukuisia muitakin malleja.
Edit. Usein web-järjestelmissä pyynnöt ottaa vastaan nk. FrontController-olio, jonka tehtävänä on hoitaa pyyntöjen reititys ja kuljetus sekä lopuksi se luo varsinaisen controller-olion pyynnön mukaan.
Jesse Korhonen kirjoitti:
kyselin lähdemateriaalia juuri teoriaan, sillä haluan myös harjotella/oppia kuinka toteuttaa ohjelmaa teorian perusteella ilman valmista koodipohjaa.
Siinä hyvä kirja:
http://shop.oreilly.com/product/0636920028062.do
Ja siinä vielä parempi:
http://www.amazon.com/Design-Patterns-Elements-Object-Oriented-ebook/dp/B000SEIBB8
XSS-aukkoihin täytyy vielä lisätä, että tietenkin edellä sanomani edellytyksenä on, ettei käyttäjän syötettä laiteta jo lähtökohtaisesti väärään paikkaan kuten script-tagien sisään tai tapahtumankäsittelijöihin tai irrallisina tagien sisään. Noihin paikkoihin syötteen lisääminen on kuitenkin jo lähtökohtaisesti sellaista puuhaa, että pitää miettiä vähän muutakin kuin tavallisia XSS-aukkoja. JavaScriptin sekaan sopivaksi syötteen saa funktiolla json_encode (ja tarvittaessa lisäksi htmlspecialchars, jottei syötteessä lue </script>). Unohdin myös mainita, että linkeistä pitää hylätä javascript-skeema ja data-skeema, jos tiedon tyyppi ei ole tunnettu. Lisäksi URLien osat kuuluu enkoodata funktiolla urlencode (GET-parametrit) tai rawurlencode (polun osat), mutta näiden puutteesta ei varsinaisesti seuraa XSS-aukkoja vaan vain vääriä osoitteita. Lisäsin vastaavat asiat lyhyesti aiempaan viestiini.
Tässä on muutama esimerkki näistä erityistapauksista. Kaikki seuraava rivit ovat siis väärin eikä htmlspecialchars-funktio edes tee niillä mitään.
<script> <?= htmlspecialchars("alert('XSS');"); ?> </script> <a href="#" onclick="<?= htmlspecialchars("alert('XSS');"); ?>">1</a> <a href="#" <?= htmlspecialchars("onclick=alert('XSS');"); ?> >2</a> <a href="<?= htmlspecialchars("javascript:alert('XSS');"); ?>">3</a> <a href="<?= htmlspecialchars("data:text/html,%3Cscript%3Ealert%28%27XSS%27%29%3B%3C%2Fscript%3E"); ?>">4</a>
qeijo kirjoitti:
Siinä hyvä kirja:
http://shop.oreilly.com/product/0636920028062.do
Kyseinen kirja vaikuttaa lupaavalta ja tulenkin sen varmaan hankkimaan joko omakseni tai lainaamaan kirjastosta. Lisäkysymyksenä ovatko O'Reillyn julkaisemat teokset minkä laatuisia näin yleensäkin, sillä tuolta näyttäisi löytyvät muitakin mielenkiintoisia teoksia?
Metabolix:ille sen verran, että itse karsastan jostain ihmeen syystä JavaSciprtia, että pyrin muutenkin toteuttamaan sivuni ilman sitä. Urlencode ja rawurlencode funktiot ovat itselleni uusia tuttavuuksia, joten kiitos niiden esittelemisestä.
Triton kirjoitti:
Edit. Usein web-järjestelmissä pyynnöt ottaa vastaan nk. FrontController-olio, jonka tehtävänä on hoitaa pyyntöjen reititys ja kuljetus sekä lopuksi se luo varsinaisen controller-olion pyynnön mukaan.
Itsekkin olen törmännyt kyseiseen asiaan tutkittuani pienempien frameworkien lähdekoodeja ja varmaan päädyn itsekkin toteuttamaan oman taustajärjestelmäni samaa periaatetta noudattaen.
Triton kirjoitti:
Jos kiinnostaa tietää, että mitä frameworkkien sisällä tapahtuu, niin kannattaa tutustua ensinnäkin valmiiden frameworkkien koodiin ja sitten kannattaa tutustua suunnittelumalleihin (eng. design patterns). MVC-mallihan perustuu lähtökohtaisesti nk. Observer-suunnittelumalliin, mutta frameworkeissä käytetään yleensä lukuisia muitakin malleja.
Täydennän tätä sen verran, että mielestäni on tärkeämpää opetella koodaamaan kyseisellä kehyksellä eikä vain lukea lähdekoodia tiedostoista. Modernit php-kehykset ovat niin järkyttävän monimutkaisia, ettei niistä ota mitään selkoa ilman ymmärrystä siitä, mitä milläkin luokalla ja funktiolla tehdään.
Varmasti näinkin, mutta pointti nyt lähinnä oli se, että jos haluaa tutustua siihen miten asiat pinnan alla toimii, niin lähdekoodia lukemalla se ainakin selviää...dokumentaatio toki auttaa ymmärtämään paremmin ja nopeammin. Mutta ei tollasen perus MVC-kehyksen koodaamiseen paria tuntia kauempaa vie, siis jos nyt puhutaan ihan siitä pelkästä rungosta. Useimmissa ohjelmistokehyksissä kun tunnetusti on kymmenittäin erilaisia komponentteja...
The Alchemist kirjoitti:
Täydennän tätä sen verran, että mielestäni on tärkeämpää opetella koodaamaan kyseisellä kehyksellä eikä vain lukea lähdekoodia tiedostoista. Modernit php-kehykset ovat niin järkyttävän monimutkaisia, ettei niistä ota mitään selkoa ilman ymmärrystä siitä, mitä milläkin luokalla ja funktiolla tehdään.
Vastaukseni taisi antaa väärän kuvan asiasta, eli olen pääosin tutusutnut alle 20 luokan järjestelmiin, joissa dokumentaatio on ollut erittäin hyvää ja useat ovat myös olleet tutorial tyyppisiä. Tämä on antanut hyvän yleiskuvan toteutustavoista ja nyt kun saan enemmän teoriaa hankittua näkemysteni ympärille uskon pystyväni toteuttamaan itselleni sopivan järjestelmän, jota uskon pystyväni myöhemminkin hyödyntämään ja päivittämään.
Myöhemmän käytön kannalta olen myös kiinnostunut näistä dokumentointitavoista, eli mikä olisi hyvä tyyli dokumentoida PHP:ssä luokat ja niiden funktiot? Onko tähän olemassa jokin automatisoitu järjestelmä (luo koodissa olevista kommenteista dokumentaation), vai kannattaako dokumentaatio kirjoittaa itse puhtaaksi lopulta suunnitelman ja toteutuksen pohjalta?
PHP:ssä on annotaatiot käytössä siinä missä javassa ja niiden perusteella voi generaattorilla tuottaa api-kuvauksen. Luokat tosin on varmaan fiksuinta dokumentoida jo ennen koodausta ja liitteenä käy hyvin luokkakaavio.
Dokumentaatioon kannattaa käyttää jotain automaattista järjestelmää (esim. Doxygen), joka kerää määrätyssä muodossa olevat kommentit lähdekoodista. Erillisen dokumentaation ylläpito käsin ei käytännössä usein toimi, koska sitä ei muisteta päivittää tai ”päivitetään myöhemmin”.
Triton kirjoitti:
PHP:ssä on annotaatiot käytössä siinä missä javassa
Tämä ei ole ollenkaan totta. Javassa annotaatio on kielen ominaisuus: niitä ei kirjoiteta kommenttilohkoihin vaan niillä on oma syntaksinsa ja niitä on myös mahdollista koodissa tutkia standardoidulla rajapinnalla. PHP:ssä ei ole tällaista ominaisuutta. PHP-tulkki tunnistaa ainoastaan kokonaisen kommenttilohkon, ja ”annotaatiot” ovat täysin mielivaltaista tekstiä, jota pitää kaivaa tuosta kommenttilohkosta omatekoisilla viritelmillä. Mielestäni PHP:ssä tämän ominaisuuden hyödyntäminen on suunnilleen yhtä typerää kuin se, että lukisi file_get_contentsilla tiedoston ja alkaisi sieltä kaivaa.
Ehkä kuitenkin tarkoitit annotaatioilla vain kommenteissa olevia dokumentaatiotekstejä. Ne eivät ole kummassakaan kielessä erityisesti osa kieltä, vaan kommentti on kielessä vain kommentti, ja kommentin sisältämä rakenteinen data kuuluu jonkin erillisen välineen tulkittavaksi. Javadoc ja Doxygen ovat melko samanlaiset.
Mun mielestä annotaatioiden hyödyntäminen ei ole php:ssä sen tyhmempää kuin missään muussakaan kielessä - valmiita moottoreita niiden parsimiseen löytyy kyllä. Sillä ei ole loppupeleissä väliä, parsitaanko annotaatiot php-tulkin toimesta vai vasta kolmannen osapuolen kirjastossa.
Esimerkiksi paljon mainostamani Doctrine ja Zend Framework sallivat käyttää annotaatioita.
Olen kyllä samoilla kannoilla The Alchemistin kanssa. Kyllä niillä pystyy aika samoja juttua tekemään Javan annotaatioiden kanssa, vaikka eivät varsinaisesti kielen syntaksiin kuuluvatkaan.
Kiitoksia hyvistä vinkeistä ja uskonkin pääsemään näillä tiedoilla eteenpäin. Tulen kyselemään myöhemmin muita kysymyksiä, jotka eivät välttämättä ole "järkeviä", mutta kuitenkin omasta mielestäni askarruttavia ja tarpeellisia. Saattanen myös jossain vaiheessa tuoda esiin oman projektini jos voin pitää sitä onnistuneena tai pidän sitä onnistumaan pyrkivänä.
Mutta yhteenvetona saamistanne vihjeistä:
Alan lukemaan seuraavaa kirjaa tarkemmin: http://shop.oreilly.com/product/0636920028062.do
Kommentoinnissa tulen käyttämään näillä näkymin esilletuomaanne Doxygenia, kun taas muut laajemmat suunnitteludokumetit toteutan oppimallani tavalla. Katsotaan sitten myöhemmin miten tämä kehittynee.
Tietoturvan osalta otan neuvoistanne vaarin ja sovellan niitä muutenkin oppimaani, niin uskon projektista syntyvän sivun olevan turvallinen käyttää.
Aihe on jo aika vanha, joten et voi enää vastata siihen.