Tervehdys,
Riittäisikö sql injektioita, CSS ja muita "normaaleja" hyökkäyksiä vastaan jos ajaa sisään tulevan syötteen strip_tags ja htmlspecialchars funktioilla?
Esimerkiksi jos oletetaan, että sivulla on vaikka hakutoiminto ja sitten käyttäjän jättämiä ilmoituksia? Pitäisikö jotain muuta ottaa vielä huomioon?
Niin ja toinen kysymys koskee sitä, että miten olisi hyvä käyttää SHA-256 menetelmää suolan kanssa salasanojen tallennukseen?
Ilmeisesti näyttäisi että hash + suola olisi tällä hetkellä paras menetelmä pikaisen googlauksen jälkeen? Ottakaa kantaa tähän!
Ensimmäiseen kysymykseen: ole aina mahdollisimman vainoharhainen käyttäjän syötteen kanssa, varsinkin tiedostoissa. GET ja POST on aina yleensä helpohkoja tarkistaa, mutta vainoharhaisuus on hyvästä niiden kanssa. Ei ole tyhmää tarkistaa tietoa monella eri tavalla, on tyhmää tallentaa ja suorittaa tiedon perusteella asioita jos siitä ei ole 100% varma, että data on juuri sitä mitä pitääkin.
Ei ole siis suoraa vastausta kysymykseesi, mutta hyvänä alkuna voidaan pitää, että SQL injektioita vastaan käytät mahdollisuuksien mukaan tietokantojen omia työkaluja kuten MySQL:ssä mysql_escape_string ja Oraclessa bind. Niillä pääsee mukavasti alkuun. Jos muuttujien dataa taas näytetään sivuilla sellaisenaan, on htmlspecialchars pohjaiset funktiot hyvä alku myös siihen. Tosin mukavia hetkiä on tiedossa kun tuot UTF8:n mukaan kuvioihin ja vanhemmat PHP versiot. =)
-W-
mysql_escape_string
--> mysql_real_escape_string ja datan filtteröintiin esim. filter-lisäosa. Suolaukseen sen verran, että muodostat jokaiselle käyttäjälle uniikin suolan (joka ei ole esim. pelkkä käyttäjänimi tmv., vaan esim. uniqid-funktiolla). Sitten on myös PDO ja erilaiset frameworkit, esim. Zend.
Hmm... netissä on kyllä valmiita GET/POST/REQUEST-syötteen filtterointi Frameworkejä.. siitä ei sit voi mennä takuuseen miten hyvin ne on tehty ja tuleeko joitakin lisäongelmia.
Zend Frameworkissä se menee jotekin näin
class myModelViewController exteds jokuLuokka
{
function jokuAction {
$var1 = $this->request('param1');
$var2 = $this->request('param2');
$sql = "DELETE FROM ..... WHERE ... $var2 AND ... $var1 ;";
try {
$db = $jotain->sqlCommit($sql);
} catch {
$view->error = "Pieleen meni!";
$logger->write('Err','Logitieto! Hakkeria potuttaa!!!')
}
$view->render();
}
}
Sori ei nyt muista ulkoo noita koodeja.. mutta kuitenkin perusidea selkiää. niin ja index.php:n luokassa taas määritellän reititykset minkälaisia URLeja voi olla ja mitä voi olla lomakedatassa.. Jotenkin näin se MVC meni.
Siis ei tarvii käyttä olenkaan noita Globaaleja..
Walkout:n vinkin jätän väliin, koska en tajunnut siitä mitään.
Jso mietitään tulevan datan tarkistamasta, niin PHP:ssa on suoraan ctype_* metodit ja sitten Zend Frameworkissa on Validate (http://framework.zend.com/manual/en/zend.
Noilla pääsee varmasti alkuun ja noita yhdistelemällä saa tarkistettua kaiken mahdollisen datan periaatteessa. Mahdollisesti suoritettavat koodit sitten erikseen tietysti.
PDO on ihan ok jos on vähän kyselyjä ja vähän tietokantaliikenne. Jos taas kantapohjaista liikennettä ja kyselyjä on paljon, niin PDO ei ole hyvä ratkaisu. PDO:ssa on turhan paljon overheadia verrattuna perinteisiin tapoihin, mutta se helppo oikotie.
-W-
Tjaa.. kun tehdään ZF:llä MVC malli niin $var1 = $this->request('param1'); jossain actionissa sitte automaagisesti otta jonkun requestin tiedot oli se sitten POST/GET/REQUEST
Eli siis lomakeen action on vaikka http://www.mydomain.invalid/controller/action/
Kananttaa katsoa mallia valmiista toteutuksista kuten vaikka Magento eCommerce vai mikä nyt olikaan koska Zend Frameworkin omissa ohjeissa ei kerrota tarkaan miten hieman isompi kokonaisuus pitäisi rakentaan ennen kun alkaa kyhätä jotain omasta päästä keksittyä MVC:n perustuvaa sydeemiä joka sitten on kuiteskin tehty väärin.
"Tehty väärin" kuten muistaakseni walkout_in
omissa ZF viritelmissä. Etusivulla (esim. se index.php) kutsutaan applikaation bootloaderia, joka hoitaa Zend_Controller_Frontin initialisoinnin ja pyöräyttää MVC-mallin käyntiin.
walkout_ kirjoitti:
Kananttaa katsoa mallia valmiista toteutuksista kuten vaikka Magento eCommerce vai mikä nyt olikaan koska Zend Frameworkin omissa ohjeissa ei kerrota tarkaan miten hieman isompi kokonaisuus pitäisi rakentaan ennen kun alkaa kyhätä jotain omasta päästä keksittyä MVC:n perustuvaa sydeemiä joka sitten on kuiteskin tehty väärin.
Kyllä Zend:n ohjeissa kerrotaan, mutta se pitää osata hakea. Lisäksi kun käyttää IDE:ä kehityksessä, niin nuo Zendin oliot on kuitenkin kommentoitu loppujen lopuksi aika hyvin, että niistä saa syöttömuodot ja return valuet aika hyvin tietää. Manuaalissa on parantamisen varaa, mutta kyllä se selkeä loppujen lopuksi on.
Ja mitä tulee MVC mallintamiseen ja arkkitehtuuriin, niin allekirjoittanut on tehnyt sitä PHP:lla ja Zendillä jo versiota 0.4 lähtien muistaakseni. Tällä hetkellä ZF:n ja oman Tiat Frameworkin päällä on esim. 450.000 käyttäjän portaali sekä sen lisäksi olen tehnyt useille työnantajille samoja hommia jo vuosikausia. Luulen tietäväni jotain ja kun sanon, että en ymmärtänyt vinkistäsi mitään, niin todellakin tarkoitin nimeenomaan sitä. En tarkoittanut ettenkö ymmärtäisi ZF:stä tai MVC puolesta jotain... ;)
-W-
Wizard kirjoitti:
walkout_ kirjoitti:
Kananttaa katsoa mallia valmiista toteutuksista kuten vaikka Magento eCommerce vai mikä nyt olikaan koska Zend Frameworkin omissa ohjeissa ei kerrota tarkaan miten hieman isompi kokonaisuus pitäisi rakentaan ennen kun alkaa kyhätä jotain omasta päästä keksittyä MVC:n perustuvaa sydeemiä joka sitten on kuiteskin tehty väärin.
Kyllä Zend:n ohjeissa kerrotaan, mutta se pitää osata hakea. Lisäksi kun käyttää IDE:ä kehityksessä, niin nuo Zendin oliot on kuitenkin kommentoitu loppujen lopuksi aika hyvin, että niistä saa syöttömuodot ja return valuet aika hyvin tietää. Manuaalissa on parantamisen varaa, mutta kyllä se selkeä loppujen lopuksi on.
Ja mitä tulee MVC mallintamiseen ja arkkitehtuuriin, niin allekirjoittanut on tehnyt sitä PHP:lla ja Zendillä jo versiota 0.4 lähtien muistaakseni. Tällä hetkellä ZF:n ja oman Tiat Frameworkin päällä on esim. 450.000 käyttäjän portaali sekä sen lisäksi olen tehnyt useille työnantajille samoja hommia jo vuosikausia. Luulen tietäväni jotain ja kun sanon, että en ymmärtänyt vinkistäsi mitään, niin todellakin tarkoitin nimeenomaan sitä. En tarkoittanut ettenkö ymmärtäisi ZF:stä tai MVC puolesta jotain... ;)
-W-
Jaa no mä olen ZF:ää alkanut vasta ite käyttämään omassa oikeassa projektissa.. teen homman Eclipsen PHP koodausversiolla. Homma on vaan niin että kun en ole tehnyt mitään laajempaa hommelia itse ZF:llä niin pitää opiskella vielä ja alkuun ainakin ne ZF:n ohjeet tuntui väliin hankalilta kun siä ei ole aina kokonaan toimivaa koodikokonaisuutta mm. zip pakettina. Eclipse ja ALM ja Subversion järjestelmä auttaa jonkun verran. Oikeastaan Eclipse on tärkein ja SVN ja ALM vaan tallentaa projektin historian palvelimelle ja kaikki koodimuutokset ja Issue Trackeriin pistetyt härpäkkeet.
Asiakkaille olen tehnyt yleensä vain valmiiseen ohjelmistoon perustuvan räätälöinnin tms. jossa on ihan oma Framework. Näissä ei aina tarvitse osata paljon muuta kuin valmiin ohjelman Framework eikä mitään kovin vaativaakaan edes yleensä tehdä.. käytännössä tehdään vain uusi leiska sydemiin ja vähän muutetaan vaikka kuvagallerian ulkonäköä. Mä aloitin IT-puolella vasta aktiivisesti vuonna 2006 ja sitä ennen olin parissa paikassa koulusta harjoitelemassa.
joku_kirjoitajista kirjoitti:
"Tehty väärin" kuten muistaakseni walkout_in omissa ZF viritelmissä. Etusivulla (esim. se index.php) kutsutaan applikaation bootloaderia, joka hoitaa Zend_Controller_Frontin initialisoinnin ja pyöräyttää MVC-mallin käyntiin.
Jos puhut TESistä joka on julkisesti esillä niin minun projekti ei ole se.. se on nyt vain yleinen tukimusprojekti enkä ole tehyt sihen mitään pitkään aikaan enkä ehkä paljoakaan aiokkaan. Ongelma tuossa oli että se oli aloitettu PHP 4 versiona ja sitten oli hankaluuksia siirtää se ZF:n eikä ollut paljon kokemustakaan ZF:stä.
Nykyinen on aloitettu tyhjästä ja tehdään ZF:n ohjeiden mukaan ja parannellaan jos ja kun tulee tarvetta. Tarkoitus on nyt vähän opiskella ennen kuin mitään vakavaa aloitetaan.
Aihe on jo aika vanha, joten et voi enää vastata siihen.