Onderwerp: veiligheid

L.S.

Ik gebruik een W2K server met IIS 5.0 en PHP 4.3.6. Ik ben redelijk vers
met zowel html en zeker met php.

Het gaat om een (foto)site voor een vereniging waar zelf foto's kunnen
worden geupload en er draait een gastenboekachtig forum. Ik heb alles
zelf geschreven met hier en daar een paar regels geleend van een
scriptsite.

Mijn veiligheidsconcept is:
1) consequent voor elke variabele $x = strip_tags($_post['x']).
2) (bijna) elke file die door het script wordt weggeschreven naar een
locatie buiten de wwwroot.
3) foto's worden gecontroleerd door: ($_FILES["foto"]['type']=="image/jpeg")
4) de router voor de server laat uitsluitend poort 80 door
5) directory browsing = off

-Klopt dit een beetje of zie ik ernstige dingen over het hoofd?
-Voor punt twee ben ik niet consequent want de ge-uploade foto's staan
wel binnen de wwwroot in een folder met schrijfrechten voor de inetuser.
Hoe los ik dat op? kan ik simpel een foto van buiten de wwwroot toch in
beeld krijgen? of is hier een andere oplossing voor?
- Is de controle in pt 3 op 'type' voldoende om zeker te weten dat het
geen .exe of een script is?

Gezien de aard van de site ben ik niet zozeer bang voor hightech hackers
maar het scriptkiddy van de hoek wil ik toch wel kunnen weghouden.
Gezien de aard van de vraag zet ik er maar even geen url bij.

bjorri.

bjorri <bjorri@hotmail.invalid> schreef:

>Ik gebruik een W2K server met IIS 5.0 en PHP 4.3.6. Ik ben redelijk vers
> met zowel html en zeker met php.
>
>Het gaat om een (foto)site voor een vereniging waar zelf foto's kunnen
>worden geupload en er draait een gastenboekachtig forum. Ik heb alles
>zelf geschreven met hier en daar een paar regels geleend van een
>scriptsite.
>
>Mijn veiligheidsconcept is:
>1) consequent voor elke variabele $x = strip_tags($_post['x']).

Waarom zou je het de gebruiker onmogelijk maken teksten binnen < en >
te gebruiken? Ik zou voor het (gebruikersvriendelijkere)
htmlentities() of htmlspecialchars() gaan op het moment dat er
informatie naar de browser als HTML wordt verzonden.

>2) (bijna) elke file die door het script wordt weggeschreven naar een
>locatie buiten de wwwroot.
>3) foto's worden gecontroleerd door: ($_FILES["foto"]['type']=="image/jpeg")
>4) de router voor de server laat uitsluitend poort 80 door
>5) directory browsing = off
>
>-Klopt dit een beetje of zie ik ernstige dingen over het hoofd?

Ik weet niet waar de gegevens precies in opgeslagen wordt, maar let
goed op dat bijvoorbeeld veldscheidingstekens van platte
tekstbestanden niet door de gebruiker kunnen worden geïmiteerd.

>-Voor punt twee ben ik niet consequent want de ge-uploade foto's staan
>wel binnen de wwwroot in een folder met schrijfrechten voor de inetuser.
>Hoe los ik dat op? kan ik simpel een foto van buiten de wwwroot toch in
>beeld krijgen? of is hier een andere oplossing voor?

Over wat voor data hebben we het hier? Ik vind het een beetje
tegenstrijdig als je aan de ene kant zegt dat je iets niet in de
wwwroot wilt hebben, maar andere andere kant wel een mechanisme wil
gebruiken die het weer wel vanuit die wwwroot bereikbaar maakt.

>- Is de controle in pt 3 op 'type' voldoende om zeker te weten dat het
>geen .exe of een script is?

Volgens mij wordt dit MIME-type gewoon door de browser opgegeven, wat
maakt dat het niet te vertrouwen is. (Kunnen er overigens alleen maar
JPEG-bestanden worden geüpload?) Je zou om .exe-bestanden en andere
gevaarlijke dingen uit te sluiten, een controle kunnen bouwen die
gebruik maakt van de GD-functies.

>Gezien de aard van de site ben ik niet zozeer bang voor hightech hackers
>maar het scriptkiddy van de hoek wil ik toch wel kunnen weghouden.
>Gezien de aard van de vraag zet ik er maar even geen url bij.

Ik denk dat je je voor iets als dit ook meer zorgen moet maken om
gewoon misbruik zoals spam en foute plaatjes.

--
Groet, Ronald

bjorri <bjorri@hotmail.invalid> wrote:

>L.S.
>
>Ik gebruik een W2K server met IIS 5.0 en PHP 4.3.6. Ik ben redelijk vers
> met zowel html en zeker met php.
>
>Het gaat om een (foto)site voor een vereniging waar zelf foto's kunnen
>worden geupload en er draait een gastenboekachtig forum. Ik heb alles
>zelf geschreven met hier en daar een paar regels geleend van een
>scriptsite.
>
>Mijn veiligheidsconcept is:
>1) consequent voor elke variabele $x = strip_tags($_post['x']).

Een goed begin, maar vergeet niet de functie 'Addslashes' te gebruiken
voor alles wat de database in gaat (naast alles wat in de database
wordt geschreen tussen "" zetten). Op deze manier is het risico op SQL
injection minimaal.

>2) (bijna) elke file die door het script wordt weggeschreven naar een
>locatie buiten de wwwroot.

Tijdelijke bestanden kun je beter in een sessie bewaren en als je ze
langer nodig hebt schrijf je ze in de database. Dat behoed je voor de
verleiding dergelijke bestanden direct te laten downloaden waardoor
men bijvoorbeeld een script (php, asp, vbs, jsp, etc, etc) zou kunnen
uploaden dat uitgevoerd wordt door de webserver. Tevens omzeil je
daarmee allerlei gedoe met rechten. Middels PHP een bestand serveren
is vrij eenvoudig; je stuurt een header met daarin het datatype en
vervolgens stuur je de data naar de client. Er moeten genoeg
voorbeelden te vinden zijn.

Vergeet niet de webserver zo te configureren dat er naar de
host-header wordt gekeken. Als iemand dan binnenkomt op je IP adres
(zoals de meeste wormen) wordt dit niet door de webserver afgehandeld.

Het is in ieder geval goed dat je de Windows machine via een
firewall/router aan internet hebt hangen.

<paranoia>
Voor het mooi zou je Squid in accellerator modus kunnen installeren
(www.squid-cache.org). Dan kun je alle verdachte URLs (bijvoorbeeld
URLs met ../ erin) filteren voordat deze op de webserver terecht
komen. De webserver stel je dan bijvoorbeeld in op poort 70, en je
laat Squid luisteren op poort 80.
</paranoia>

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Ronald Paul wrote:
> bjorri <bjorri@hotmail.invalid> schreef:
>
>
>>Ik gebruik een W2K server met IIS 5.0 en PHP 4.3.6. Ik ben redelijk vers
>> met zowel html en zeker met php.
>>
<< htmlentities() of htmlspecialchars >>
>
Het flauwe antwoord is dat ik de functie niet kende. Dit is een
verbetering die ik zeker ga doorvoeren.

>
>>2) (bijna) elke file die door het script wordt weggeschreven naar een
>>locatie buiten de wwwroot.
<<>>
> Ik weet niet waar de gegevens precies in opgeslagen wordt, maar let
> goed op dat bijvoorbeeld veldscheidingstekens van platte
> tekstbestanden niet door de gebruiker kunnen worden geïmiteerd.
>
Ik neem aan dat dit alleen voor databasegebruik telt, omdat ik niet
direkt ook nog mysql wil leren heb ik alles opgelost met txt files,
voorlopig goed werkbaar, echter niet echt schaalbaar.

<<>>

> Over wat voor data hebben we het hier? Ik vind het een beetje
> tegenstrijdig als je aan de ene kant zegt dat je iets niet in de
> wwwroot wilt hebben, maar andere andere kant wel een mechanisme wil
> gebruiken die het weer wel vanuit die wwwroot bereikbaar maakt.
>
Mogelijk zie ik dingen volkomen verkeerd maar mijn redenatie is dat als
ik (foto)bestanden wil laten uploaden dan MOET de inet_user
schrijfrechten krijgen in die uploadmap, als die map binnen de wwwroot
staat lijkt mij het niet onmogelijk dat iemand daar buiten mijn script
om daar ook iets kan wegschrijven. Voor een map buiten de wwwroot lijkt
me dat redelijk omogelijk.

[quote uit posting van Nico]
Tevens omzeil je
daarmee allerlei gedoe met rechten. Middels PHP een bestand serveren
is vrij eenvoudig; je stuurt een header met daarin het datatype en
vervolgens stuur je de data naar de client. Er moeten genoeg
voorbeelden te vinden zijn.
[/quote]

Die rechten kwestie is dus mijn probleem en dat probeer ik dus inderdaad
op die manier op te lossen. Ik ga op zoek naar die voorbeelden.


> Volgens mij wordt dit MIME-type gewoon door de browser opgegeven, wat
> maakt dat het niet te vertrouwen is. (Kunnen er overigens alleen maar
> JPEG-bestanden worden geüpload?) Je zou om .exe-bestanden en andere
> gevaarlijke dingen uit te sluiten, een controle kunnen bouwen die
> gebruik maakt van de GD-functies.
>
Heb ik weer wat te doen deze week :-) GD functies heb ik geactiveerd,
kan je een trefwoord geven hoe ik dat aanpak?

Elke camera produceert jpg, daarnaast zijn een paar andere mime type's
ook mogelijk, als via GD een simpele controle mogelijk is op alle
plaatjes bestanden is dat beter natuurlijk.
>
<<>>
> Ik denk dat je je voor iets als dit ook meer zorgen moet maken om
> gewoon misbruik zoals spam en foute plaatjes.
>
Voor de gebruikersvriendelijkheid wil ik liever niet (direkt) met
aanmelden/wachtwoorden werken.
Foute plaatjes en forumbijdragen kunnen via een omweg op internet
verwijderd worden door drie personen, moet vooralsnog voldoende zijn,
dat kan altijd nog aangepast worden.

Ik verzin net dat het misschien wel slim is om 'overal' waar een
emailadres ingevuld kan worden dat veld ook te kontroleren op de
aanwezigheid van (punt)komma's en dubbele punten. Dan vang ik
waarschijnlijk af dat er bulkmail verzonden kan worden. Mogelijk moet ik
ook eens nadenken voor een construktie dat per sessie (of per ip-adres
per kwartier) slechts een mailtje kan worden verzonden.

Hartelijk dank alvast,

bjorri.

bjorri <bjorri@hotmail.invalid> schreef:

>> Ik weet niet waar de gegevens precies in opgeslagen wordt, maar let
>> goed op dat bijvoorbeeld veldscheidingstekens van platte
>> tekstbestanden niet door de gebruiker kunnen worden geïmiteerd.
>
>Ik neem aan dat dit alleen voor databasegebruik telt,

Juist niet, maar het is wel vergelijkbaar. Uit jouw verhaal maakte ik
al een beetje op dat je met platte-tekst-bestanden werkt. Stel dat je
in zo'n bestand velden (naam, bericht, enz.) scheidt met een tab en
records met een newline, wat gebeurd er dan als de gebruiker zo'n tab
of newline ín een van die velden ingeeft?

>> Over wat voor data hebben we het hier? Ik vind het een beetje
>> tegenstrijdig als je aan de ene kant zegt dat je iets niet in de
>> wwwroot wilt hebben, maar andere andere kant wel een mechanisme wil
>> gebruiken die het weer wel vanuit die wwwroot bereikbaar maakt.
>
>Mogelijk zie ik dingen volkomen verkeerd maar mijn redenatie is dat als
>ik (foto)bestanden wil laten uploaden dan MOET de inet_user
>schrijfrechten krijgen in die uploadmap, als die map binnen de wwwroot
>staat lijkt mij het niet onmogelijk dat iemand daar buiten mijn script
>om daar ook iets kan wegschrijven. Voor een map buiten de wwwroot lijkt
>me dat redelijk omogelijk.

Oke, da's duidelijk.

>> Volgens mij wordt dit MIME-type gewoon door de browser opgegeven, wat
>> maakt dat het niet te vertrouwen is. (Kunnen er overigens alleen maar
>> JPEG-bestanden worden geüpload?) Je zou om .exe-bestanden en andere
>> gevaarlijke dingen uit te sluiten, een controle kunnen bouwen die
>> gebruik maakt van de GD-functies.
>
>Heb ik weer wat te doen deze week :-) GD functies heb ik geactiveerd,
>kan je een trefwoord geven hoe ik dat aanpak?

Met de functie imagecreatefromjpeg() en zijn broertjes
imagecreatefrom*() moet je een heel eind komen. Het geüploadde plaatje
hier gewoon mee proberen te openen. Als het lukt ben je vrijwel zeker
van een valide plaatje.

Succes ermee!

--
Groet, Ronald

Ronald Paul wrote:
> bjorri <bjorri@hotmail.invalid> schreef:
>
<<>>
> Uit jouw verhaal maakte ik
> al een beetje op dat je met platte-tekst-bestanden werkt. Stel dat je
> in zo'n bestand velden (naam, bericht, enz.) scheidt met een tab en
> records met een newline, wat gebeurd er dan als de gebruiker zo'n tab
> of newline ín een van die velden ingeeft?
>
OK, helemaal duidelijk. Teksten worden onmiddelijk geconverteerd naar
html (meestal iets als<tr><td> naam </td><td> verhaal </td></tr> of naar
een foto webpagina met vaste indeling), dus newline gaat door nl2br en
tab wordt genegeerd. Ik gebruik ergens wel een * en een # als scheiding
tussen emailadressen, dus een emailadres met een * creeert twee foute
mailtjes, de # verhinderd de verzending. In de rfc 822 en 2822 kan ik
niet vinden welke tekens ongeldig zijn in emailadressen (het deel voor
de @) maar ik heb nog nooit een adres met een * of # gezien. :-(
>
<<>>

>>>Je zou om .exe-bestanden en andere
>>>gevaarlijke dingen uit te sluiten, een controle kunnen bouwen die
>>>gebruik maakt van de GD-functies.
>>
>>Heb ik weer wat te doen deze week :-) GD functies heb ik geactiveerd,
>>kan je een trefwoord geven hoe ik dat aanpak?
>
>
> Met de functie imagecreatefromjpeg() en zijn broertjes
> imagecreatefrom*() moet je een heel eind komen. Het geüploadde plaatje
> hier gewoon mee proberen te openen. Als het lukt ben je vrijwel zeker
> van een valide plaatje.

Ben net heel druk aan het studeren op getimagesize, dat bied
waarschijnlijk ook mogelijkheden, maar is niet zalig makend. Wel kan ik
in een moeite door te grote foto's alsnog kleiner maken :-)
(If accessing the filename image is impossible, or if it isn't a valid
picture, getimagesize() will return FALSE and generate a warning. )
Jou oplossing is waarschijnlijk beter omdat de afmeting van de image
niet verplicht in de header zit.
>
> Succes ermee!
>
Yes!! Dankje, ik ben er wel zo mooi mee aan't spelen. :-)

bjorri.

bjorri <bjorri@hotmail.invalid> wrote:

>
>Ik verzin net dat het misschien wel slim is om 'overal' waar een
>emailadres ingevuld kan worden dat veld ook te kontroleren op de
>aanwezigheid van (punt)komma's en dubbele punten. Dan vang ik
>waarschijnlijk af dat er bulkmail verzonden kan worden. Mogelijk moet ik
>ook eens nadenken voor een construktie dat per sessie (of per ip-adres
>per kwartier) slechts een mailtje kan worden verzonden.

Ook daar zijn kant en klare routines voor te vinden (deze controleren
de domeinnaam). Sommige routines gaan echter te ver door te
controleren of ze een e-mail op de host kunnen afleveren. De maker
heeft zich niet gerealiseerd dat niet iedere mailserver direct aan
internet hangt. Zo'n controle moet je er dan uit slopen.
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl