Kirjautuminen

Haku

Tehtävät

Keskustelu: Nettisivujen teko: Webrootin ulkopuoliset tiedostot selaimelle

Sivun loppuun

Triskal [17.10.2009 14:35:24]

#

Sen tiedän, että php:lla pääsee käsiksi webrootin ulkopuolella oleviin tiedostoihin, mikä on hyödyllistä siinä kohtaa kun esim tietokantojen konffitiedot pitää saada pois asiattomien ulottuvilta.

Mutta entäs ne muut tiedostot? Kokeilin jo ladata <img>-tagilla kuvan webrootin ulkopuolelta, mutta ei suoraan näyttänyt onnistuvan. Esteetikko minussa tykkäisi nimittäin siitä, että webrootissa olisi vain yksi ainoa tiedosto: index.php ja että kaikki muu sijaitsisi suoran osoiteriviaccessin ulkopuolella.

Miten se tehdään, vai voiko sitä tehdä?

Kray [17.10.2009 14:52:56]

#

Ei onnistu jos palvelin ei tarjoile tavaraa sieltä missä tiedosto on. Yksi vaihtoehto tietysti olisi php-skripti joka antaa halutun tiedoston.

Metabolix [17.10.2009 14:54:01]

#

Ei img-tagilla ole mitään tekemistä PHP:n kanssa. WWW-root on se paikka, johon HTTP-pyynnöt kohdistuvat: Jos www-root on /palvelin/triskal/sivut ja palvelimelle tulee pyyntö kuvasta /img/kuva.png, palvelin palauttaa tiedoston /palvelin/triskal/sivut/img/kuva.png. Toisin sanoen jokaiseen pyynnön tiedostonimeen lisätään alkuun polku /palvelin/triskal/sivut, eikä tämän ulkopuolelta voi hakea tiedostoja.

On säädetty, että jos pyydetyn tiedostonimen pääte on .php, tiedosto ajetaan PHP-tulkilla. Tällöin skripti toimii palvelimella aivan kuin mikä tahansa muukin ohjelma, eikä tässä vaiheessa WWW-rootilla ole enää mitään tekemistä asioiden kanssa. (Joillain muilla asetuksilla voidaan sitten rajoittaa skriptin oikeuksia, mutta se on aivan eri asia.)

Jos välttämättä haluat toteuttaa ideasi, voit tietysti tehdä index.php-tiedoston, joka GET-parametrien (?sivu=abc) perusteella hakee tiedostoja. Tällöin kuvan osoite voisi olla vaikkapa index.php?hae=kuva.png. Tästä ratkaisusta ei kuitenkaan ole yhtään mitään hyötyä, jos kuvan saa ladattua joka tapauksessa. Haittaa sen sijaan on: viritelmästä tulee väkisinkin epäselvempi kuin selkeästä hakemistojaottelusta, ja lisäksi sivusto hidastuu, kun joka asiaan sotketaan aivan turhaan vielä PHP-tulkki. Myös tietoturvan kanssa pitää olla tarkkana, ettei skripti vahingossa anna käyttäjän ladata salasanat.php-tiedostoa.

Triskal [17.10.2009 18:02:15]

#

Juu, mutku katoku mä ajattelin näin, että jos www-root on /palvelin/triskal/public_html ja siellä on index.php. Kuvat ois vaikka hakemistossa /palvelin/triskal/img ja silloin index.php:hen tavalla tai toisella renderöitävä tagi hakisi kuvan tyylillä <img src="../img/kuva.png" />.

Ajattelin, että mahtaisiko olla mahdollista jollain .htaccess konstilla olla mahdollista kanavoida kyseiset kutsut, koska ainakin tuon palvelin torppaa, eli ei päästä ylempään hakemistoon.

Mutta se ei vissiin sitten ole mahdollista. :( Onneksi koko hässäkän idea oli puhtaasti esteettinen.

Metabolix [17.10.2009 20:24:25]

#

<img src="../img/kuva.png" />
<img src="http://palvelin.com/../img/kuva.png" />

Ei toimi kumpikaan. Entä olisiko tämä sinusta mukava ominaisuus:

<iframe src="http://palvelin.com/../../../etc/passwd"></iframe>

Sitä varten se www-root on keksitty.

En myöskään ymmärrä tämän jutun esteettistä arvoa. Eikö ole paljon selkeämpää, että kaikki, mihin käyttäjällä pitäisi olla pääsy, on sijoitettu loogisesti www-root-hakemistoon?

Eipä siitä sen enempää. Asia kaiketi tuli jo selväksi. :)

Triskal [17.10.2009 21:23:33]

#

Metabolix kirjoitti:

Entä olisiko tämä sinusta mukava ominaisuus:

<iframe src="http://palvelin.com/../../../etc/passwd"></iframe>

Sitä varten se www-root on keksitty.

En ole ihan niin tyhmä (enkä sen puoleen ihan niin vihreä näissä hommissa), että tuo olisi minusta mukava ominaisuus.

Ajatukseni oli se, että jos vaikka olisi mahdollista tehdä ero skriptin tekemän http-kutsun ja osoiteriviltä "suoraan" tulevan, tai jostain toiselta palvelimelta ajettavalta skriptiltä tulevien http-kutsujen välillä, niin silloin voisi olla jotain itua antaa kutsuille erilaisia valtuuksia. Mutta näin siis ei ole. Se on ihan ok.

Metabolix kirjoitti:

En myöskään ymmärrä tämän jutun esteettistä arvoa.

Se ei haittaa, riittää kun minä ymmärrän itse. :)

Grez [17.10.2009 21:27:07]

#

Triskal kirjoitti:

Se ei haittaa, riittää kun minä ymmärrän itse. :)

Ei tuossa muuten mitään, mutta varmaan turhaa yrittää saada ratkaisua johonkin, jossa kukaan muu ei näe ongelmaa.

Triskal [17.10.2009 21:29:44]

#

Grez kirjoitti:

Triskal kirjoitti:

Se ei haittaa, riittää kun minä ymmärrän itse. :)

Ei tuossa muuten mitään, mutta varmaan turhaa yrittää saada ratkaisua johonkin, jossa kukaan muu ei näe ongelmaa.

Kyseessä ei olekaan ongelma, vaan ihan vaan se, että voiko niin tehdä.

Metabolix [17.10.2009 22:09:42]

#

Triskal kirjoitti:

... skriptin tekemän http-kutsun ...

Mutta kun ei se skripti tee yhtään HTTP-kutsua. Se tulostaa img-tagin, ja selain tekee (tai tekstiselain jättää tekemättä) HTTP-pyynnön, jolla pyytää tagin ilmoittamaa kuvaa. Kaikki HTTP-pyynnöt tulevat siis yhdestä ja samasta lähteestä, selaimelta.

Siinä olet kuitenkin oikeassa, että vaikka tehtäisiinkin PHP-skriptillä HTTP-pyyntö, se menisi aivan samojen mekanismien kautta ja noudattaisi samoja sääntöjä. Ei vain ole mitään järkeä tehdä PHP:llä HTTP-pyyntöä, jos tiedoston voi lukea suoraan levyltäkin.

Siitä toivottavasti olet tietoinen, että PHP-skriptin suorittaa palvelin eikä selain; selaimen ei tarvitse edes tietää, että kyseessä on PHP-skripti eikä tavallinen HTML-sivu. (Asia tuntuu olevan joskus ammattilaisillekin vieras. O_o)

Triskal [17.10.2009 22:21:10]

#

Metabolix kirjoitti:

Mutta kun ei se skripti tee yhtään HTTP-kutsua. Se tulostaa img-tagin, ja selain tekee (tai tekstiselain jättää tekemättä) HTTP-pyynnön, jolla pyytää tagin ilmoittamaa kuvaa. Kaikki HTTP-pyynnöt tulevat siis yhdestä ja samasta lähteestä, selaimelta.

Okei, nyt ymmärsin mikä ajattelussani mätti. No further questions.

lainaus:

Siitä toivottavasti olet tietoinen, että PHP-skriptin suorittaa palvelin eikä selain; selaimen ei tarvitse edes tietää, että kyseessä on PHP-skripti eikä tavallinen HTML-sivu. (Asia tuntuu olevan joskus ammattilaisillekin vieras. O_o)

Olen ollut tietoinen asiasta siitä lähtien kun viisi vuotta sitten tutustuin PHP:hen ensi kertaa.


Sivun alkuun

Vastaus

Aihe on jo aika vanha, joten et voi enää vastata siihen.

Tietoa sivustosta