Ylen verkkosivuille murtauduttiin

Onhan se aina mahdollista, mutta PHP:llä se vain on tehty siten että lähes kuka tahansa voi näitä koodissa olevia reikiä käyttää hyväksi.

Se että voidaan koodia kirjoitella tyyliin

{$taman_funkkarin_nimi}($funkkarille_parametri);

tai

include($tama_php_tiedosto)

voi jonkun mielestä tuoda vain lisää joustavuutta ohjelmointiin, ja taas toisen mielestä olla kirosana.

Omasta mielestäni sekäettä (näillä saa hyvin kierrettyä PHP:n puutteellisia OO-ominaisuuksia, jos niitä tuntee tarvitsevansa), mutta toisaalta lisää taas päänsärkyä koska asiat on tehtävä kerralla toimiviksi, etteivät nämä väärinkäytökset ole mahdollisia.

Tarkennus, ainahan niitä aukkoja on, ei vaan tunnettuja tällä hetkellä ;) Mutta muuten totta, millä tahansa kielellä saa (yllätysyllätys) tehtyä aukkoja, toisilla se vaan on helpompaa (ja niiden käyttö on helpompaa) kuin toisilla.

Ohjelmointikielen / ohjelmoijan syyttämisestä en lähde väittelemään, mutta tärkeintä tässä on nyt ymmärtää että nämä "väärinkäytökset" ovat aina ensisijaisesti tekijän vastuulla. Mahdollisuus "rikokseen" ei anna siihen edelleenkään oikeutta.

Akateemisessa mielessä PHP jättää liian monta ovea, auki, se on yksinkertaisesti "liian" joustava kieli että kaikki sitä käyttävät voisivat ymmärtää jo itsessään PHP:n antamien mahdollisuuksien tuomia riskejä.

Tästä sitten en tiedä, kuulostaa vähän urbaanilta legendalta, jos edes siltään.

Riippuen tietenkin mitä teet, itse emme ainakaan tee tuotteita siitä näkökulmasta että niitä pääsääntöisesti yritettäisiin käyttää väärin. (vaikkakin joudumme validoimaan ja todistamaan tietoturvalliset seikat melko formaalisti)

Väärin käytettynä tämä on kirosana. Eritoten includea ei tulisi _ikinä_ käyttää näin, ylen ollessa esimerkkinä.

Eipäs tuota. Alusta asti vain kirjoittaa koodin pitäen perusasiat turvallisuudesta muistissa.

Niin. PHP:llä se vain ei ole helpompaa kuin muilla. Includetus pätee perliin siinä missä peehoopeehenkin, mikäli ohjelmoijalla ei ole minkäännäköisiä perusasioita hallussa. C/C++ puskurin ylivuodot ovat varsin yleisiä, kuten varmaan olet tietuturvaraporteista huomannut (oli sitten kyseessä mikä käyttöjärjestelmä vain), ja näitä on helppo mokailla koodiin oikein urakalla yömyöhäisellä koodatessa :)

Mutta tuohan ei ole minkäännäköinen murtautuminen. Ohjelmoija on tehnyt "featuren" joka ilman mitään estoa (mikä pitäisi murtaa) sallii minkä tahansa tiedoston liittämisen.

Et ilmeisesti ole sitten ollut paljoa tekemisissä Perlin kanssa ;)

Mainitaan myös joka ikisessä weppiohjelmointiin liittyvässä kirjassa. Hop mars kirjastoon ja lainaamaan vaikkapa Web programming with PHP 4.0 :)

PHP:täpä hyvinkin :) Kukapa tuotetta tekisi siitä näkökulmasta että sitä käytettäisiin väärin. Mutta turvallisuus tulee aina pitää mielessä, eritoten web-pohjaisessa ohjelmoinnissa. Aina, ja koko ajan. Sama pätee kaikkiin ohjelmiin jotka ovat intternjettiin yhteydessä.

Yleisradiolla on riittävän suuret tiedotuskanavat tähän ja itseasiassa näistä kuuluisi aina ja heti tehdä rikosilmoitus.

Pilailua tuo minusta oli ja Ylen pitäisi olla tyytyväinen ettei isompia tapahtunut, siihen kun oli kaikki eväät tässä. Hieman huonon kuvan Ylen ammattitaidosta tuo antaa kyllä.

Oletat että koodi oli väännetty talon sisällä. Laittaisin potin yhden konkurssin puolesta...

Tarkentaen vielä siitä, että se että jos itse serverille ei tehdä mitään niin ei se silloin rikollista pitäisi olla. =)


+V

Mutta eihän sekään ole varkaus (= iso rikos) vaan luvaton käyttöönotto ;)

Ei tietenkään. Mutta sillä ei ole mitään tekemistä tämän koko jutun kanssa.

Bullshit. Kahden servletrunnerin käyttäminen on paitsi resurssisyöppöä myös tietoturvan kannalta ongelmallista koska yhden päivitettävän ohjelman ja jar-läjän sijasta näitä onkin kaksi. Tämän lisäksi tämä ei ratkaise tapausta jossa tietoa joudutaan jakamaan eri jsp-sivujen välillä.

Oikeasti jsp-sivuilla ei tietenkään tarvi olla mitään turvallisuustakuita koska itse servletrunneria ajetaan sellaisilla oikeuksilla että tuhmuuksia ei pääse tekemään.

En ole kyllä tällaisesta ikinä kuullut, tietoturva on suunnittelusta kiinni ei mistään miljoonasta purkkatarkistuksesta. Tällaiset syövät varmaankin tehoa mutta tuovat vain näennäistä tietoturvaa mikäli pohja on huttua.

Ja taas löpönlöpöä ja vaikealta kuullostavia sanoja pelottelemaan keskustelun kävijöitä. Kuvien "loadbalancingissa" riittää oikeasti että otat palvelimen ja pistät ne kuvat sinne. Jos se palvelin kiikahtaa kuorman alla, otat toisen palvelimen ja pistät nimipalvelimelle uuden entryn samalla nimellä sille toiselle palvelimelle. roundtroobing on valmis.

No hellan lettas. Voidaan asia tehdä toisellakin tavalla, mutta aina menee resursseja, siitä ei pääse mihinkään.
koska yhden päivitettävän ohjelman ja jar-läjän sijasta näitä onkin kaksi.

Niin tietoturva ei ole välttämättä kovinkaan helppoa.

Tämän lisäksi tämä ei ratkaise tapausta jossa tietoa joudutaan jakamaan eri jsp-sivujen välillä.
Oletko tosiaan noin tyhmä vai pitääkö antaa oikein esimerkki. Tiedätkö esimerkiksi mitä tarkoittaa SSL. Se on yksi esimerkki jo tasapainoilusta performancen ja tietoturvan kanssa. Mutta eipä sinulla taida olla mitään käsitystä kuinka rakennetaan järjestelmiä joiisa on mahdollista suorittaa esimerkiksi luottokortti maksamista.
Oletkos ikinä kokeillut tehdä saittia jonka täytyy täyttää lainsäädännölliset vaatimukset esimerkiksi saksassa. Voin olla varma että et ole.

Niin oletuksessasi vain on hevosen kokoisia reikiä.
esimerkiksi jos palvelin ei kaadu vaan vastaa pyyntöihin, mutta liian hitaasti. Oletkohan koskaan joutunut tekemään tämän alan töitä oikeasti ? Oletko kuullut esimerkiksi availability target luvusta. Eli jos halutaan että palvelu vastaa tietyn ajan kuluessa palvelupyynnöstä Esimerkiksi alle 3 sekunninn kuluessa pyynnöstä. Siinä ei sinun nimipalvelu virityksesi vie sinua kovinkaan pitkälle jos palvelin vastaa, mutta vasta 30 sekunnin kuluessa pyynnöstä.
Entä oletko koskaan kuullut että performance ongelmat ovat tyypillisesti kumulatiivisia ongelmia, joita ei voi laskea 2+2=4 vaan yleensä kaava saattaa olla jopa 2+2=6.

Niinpä niin. itse olen tietoturva päällikköna toiminut jo 3 vuotta, vastuuna minulla on yksi maailman suurimmista saiteista, johon kokonaisuutena kuuluu usean sadan Solaris palvelimen joukko.
Tuolla sinun "kuvittelemallasi" järjetelyllä olaan kyllä todella suurissa vaikeuksissa jos puhutaan suuren käytettävyyden ja käyttäjä määrän palveluista.
Paitsi että kyllä sinun kotisivut noin voisi toteuttaa, mutta kun vastassa on Globaalit lainsäädökset privacy, legal yms. joihin pitää vastata erityyppisillä konfiguraatioilla. Sekä sovellusten kehittäjä joukko joka toimii useassa maassa yhtä aikaa. On asiat "hieman" monimutkaisempia kuin sinun kaltaisen putkiaivon esittämät ratkaisut.

Katso alla.

Tämä menee kyllä täysin off-topiciksi, mutta vastataan kun kerran on tuttua tekniikkaa :)

Onhan se DNS round robin aikamoinen "viritys". Lisätään monta IN A recordia samalle hostinimellä ja luotetaan siihen että yksittäiset nimipalvelimet looppaavat sitä listaa. Keräsin pienen taulukon alle jossa on hyödyt ja haitat verrattuna loadbalansointiin L4-L7 kytkimillä:

+ Halpa toteuttaa (ei vaadi rautainvestointeja)
+ Uuden palvelimen lisääminen on vaivatonta
- Ei jaa kuormaa oikeasti tasaisesti kaikille palvelimille
- Ei suoriudu hyvin mikäli poolissa on eri teholuokan servereitä
- Ei automaattisesti tunnista mikäli palvelin on hajonnut tai ei vastaa (healthcheck)
- Ei mahdollista ohjata liikennettä QUERY_PATH:n perusteella
- Palvelimen tiputtaminen ryhmästä esim lyhyen huollon ajaksi ongelmallista, riippuen zonen TTL arvoista
- Mikäli clientti päättääkin syystä X resolvata uudestaan URL:n domainosan, saattaa pyynnöt ohjautua eri palvelimille (sessioiden jatkuvuus). Vrt esim L4-L7 kytkimien HASH mahdollisuuteen
- Ei helppoa liitosta SSL acceleraattoreihin

DNS:llä saa toki muita kivoja kikkailuja tehtyä (ainakin pienellä vaivalla), kuten esim requestien ohjautuminen verkollisesti lähimmälle serverille (esimerkkinä Akamai). Paras lopputulos saadaan kuitenkin hyödyntämällä sekä hardware pohjaisia loadbalancereita että DNS:ää, joka onkin aika yleistä varsinkin hyvin isoilla webbisiteillä.

Kiitos. Tällaista vastausta olisin kaivannut alunperinkin enkä "mä olen päällikkö sä et mitään" hölynpölyä.

+1 sanoisin itse jos voisin moderoida

Mikään viritys roundrobin ei kuitenkaan ole, etenkin staattisen datan jakamisessa se toimii varsin hyvin, tottakai älykkäät reitittimet toimivat paremmin etenkin todellisen taakanjakamisen kanssa koska dns ei tosiaan voi mistään tietää onko serveri päällä tai senhetkisetä taakasta.

Itse käyttäisina todellisessa isossa ratkaisussa älykästä reititintä, round robinilla tai jollain muulla ratkaisuilla (esim. akamain suljettu ratkaisu) voi tietysti lisätä varmuutta jos saitti on hajautettu maantieteellisesti tai halutaan kahdentaa myös itse letku.

(ja olen tosiaan se edellinen hiukan tulikivenkatkuisen viestin kirjoittaja-anonyymi)

Ja toiseen viestiisi, kaveri sanoi että hänellä on vastuullaan monen sadan solaris-pöntön klusteri _yhtä_ saittia varten, ei datacenteriä. Niitä toki tiedän suomessa olevan montakin tuossa kokoluokassa.

Ei ajettu, eikä vika ollut PHP:ssä. PHP:n asetuksissa oli silti vikaa, kun pystyttiin osoittamaan ulos webbihakemistosta. Jos Apachea olisi ajettu roottina, se kone olisi ollut hetkessä murtautujien käytössä.

Sitä lähinnä meinasinkin..
No, ehkä tiivistän asiani pikku analogialla:

Jos alakerran naapuri unohtaa ovensa auki lähtiessään mökille, tönäänkö oven kiinni vai soitanko kaikille kavereille ja pidän kämpässä elämäni bileet?

Tää on aina tätä.. ja muutakin kuin irkkipasten klikkailua mitä teen itsekin.

Entäs jos joku muu on laittanut oven viereen kyltin että bileet siihen ja siihen aikaan. Erittäin huono vertaus yksityisen kämpän vertaaminen julkiseen palveluun.

Kyse on julkisesta paikasta eli sama kuin kaupassa on valot päällä ja auki ja kuljet siellä. Pukukoppiin mennes menetkin vahingossa henkilökunnan ovesta kun joku unohtanut sen auki.
Tai niinkuin eräässä kaupassa kävi itselle joskus. Kävelit kaupas ja huomaat et hemmetti nyt en olekkaan enää kaupan puolella vaan varastossa. Oliko tämä sitten murtautuminen..
Eri juttu jos olisi kyltti henkilö kunnalle ollut jonka olisin muutta ei henkilökunnalle tjs.