Best practice voor beveiliging map

[P.O. Box]

Ik heb website www.website.nl en daarin een admin systeem www.website.nl/admin... de eigenaar van de site kan nu via de admin images uploaden die in de map www.website.nl/images worden gezet. Om dit te laten werken kan ik de map /images rechten 777 geven. Dit lijkt mij niet de bedoeling.
Mijn vraag is nu, wat is de beste manier om dit op te lossen? Het enige wat ik zelf kan bedenken om dit veilig te krijgen is om de images map buiten de webroot te zetten en dan via een scriptje de images op te halen (bijv. getimage.php?id=12). Maar ik het het gevoel dat het simpeler moet kunnen.

[OkkE]

Je zou eens kunnen kijken naar hotlink beveiligingen, maar ik vind "buiten de webroot" wel de beste oplossing wanneer je niet wil dat bestanden rechtstreeks aangeroepen kunnen worden.

Is de vraag in dit geval; waar wil je de images tegen beschermen?

[NMe]

Waarom is een chmod naar 777 niet de bedoeling volgens jou?

[Verwijderd]

Misschien is het een gedeelde server. In dat geval is 0770 of 0775 beter, mits de webserver groepsrechten heeft op die map.

[MueR]

Aangezien een webserver (zeker de gemiddelde pizzadozenhoster) over het algemeen apache onder een gebruiker met heel weinig rechten draait, lijkt me dat niet geweldig waarschijnlijk Tinctorius. Ik ben met NMe in deze: wat is er mis met 777?

[P.O. Box]

het gaat me er niet om dat de images niet benaderbaar mogen zijn. dat is geen probleem. Ik dacht dat ik met 777 de boel wagewijd openzette voor duistere figuren...

in fact, ongeveer een maand geleden was mijn eigen website gehacked met de melding "By Lewis" en na googlen vond ik dat dat kon komen omdat er mappen met rechten 777 binnen de webroot stonden waar die hacker gebruik van maakte.

heb ik me gewoon laten misleiden door indianenverhalen over de bewuste hacker? (en zo ja, dan vraag ik me toch ernstig af hoe het mogelijk is dat hij mijn site gehacked had - overigens heb ik de mappen tot nog toe gewoon op 777 laten staan omdat ik niet wist wat ik moest doen en heb ik alleen mijn FTP wachtwoord gewijzigd...).

dus volgens jullie kan 777 geen kwaad?

ik wil eigenlijk bereiken dat iemand die is ingelogd via de admin (via htaccess file) wel schrijfrechten heeft op de map, en ieder ander niet...

[ Voor 8% gewijzigd door P.O. Box op 19-10-2010 16:26 ]

[CodeCaster]

P.O. Box schreef op dinsdag 19 oktober 2010 @ 16:24:
het gaat me er niet om dat de images niet benaderbaar mogen zijn. dat is geen probleem. Ik dacht dat ik met 777 de boel wagewijd openzette voor duistere figuren...

in fact, ongeveer een maand geleden was mijn eigen website gehacked met de melding "By Lewis" en na googlen vond ik dat dat kon komen omdat er mappen met rechten 777 binnen de webroot stonden waar die hacker gebruik van maakte.

heb ik me gewoon laten misleiden door indianenverhalen over de bewuste hacker? (en zo ja, dan vraag ik me toch ernstig af hoe het mogelijk is dat hij mijn site gehacked had - overigens heb ik de mappen tot nog toe gewoon op 777 laten staan omdat ik niet wist wat ik moest doen en heb ik alleen mijn FTP wachtwoord gewijzigd...).

dus volgens jullie kan 777 geen kwaad?

ik wil eigenlijk bereiken dat iemand die is ingelogd via de admin (via htaccess file) wel schrijfrechten heeft op de map, en ieder ander niet...

Een schrijfbare directory moet wel door iemand worden geschreven. In het geval van een hacker die enkel en alleen via HTTP (en dus in sommige gevallen via PHP) je server benadert moet er een (bekend) lek zitten in één van de PHP-scripts. Wellicht staat het upload-script het uploaden van alle soorten bestanden in alle schrijfbare directories toe? Als hij dan een nieuwe index.php in de map "/images/../" uploadt, ben je je oorspronkelijke index.php uit je root kwijt.

NMe, typ jij mijn post tien minuten later even over

[NMe]

P.O. Box schreef op dinsdag 19 oktober 2010 @ 16:24:
het gaat me er niet om dat de images niet benaderbaar mogen zijn. dat is geen probleem. Ik dacht dat ik met 777 de boel wagewijd openzette voor duistere figuren...

in fact, ongeveer een maand geleden was mijn eigen website gehacked met de melding "By Lewis" en na googlen vond ik dat dat kon komen omdat er mappen met rechten 777 binnen de webroot stonden waar die hacker gebruik van maakte.

Je hebt niet helemaal goed lopen zoeken denk ik. Dat die directory op 777 staat wil niks zeggen, want als zo'n hacker geen fysieke toegang tot de server heeft kan hij hier niets mee, tenzij er een softwarematig lek aanwezig is die toegang op afstand mogelijk maakt. Als iemand om jouw beveiliging heen komt en dus in plaats van bijvoorbeeld een plaatje een PHP-script uploadt, dan is het hek van de dam. Die 777 van de map veranderen in 644 gaat dus het hackprobleem niet oplossen, je code goed beveiligen/indekken wel.

[P.O. Box]

al mijn scripts zijn zelf geschreven.. dus een bekend lek kan het niet zijn en volgens mij heb ik alle schrijfacties van te uploaden bestanden in het admin-gedeelte zitten en die zijn dus niet zonder password bereikbaar. Vraag me dan toch af hoe de hacker aan mijn gegevens is gekomen, maar goed, daar was dit topic niet voor bedoeld

ik kan dus lekker doorgaan met 777-en? das mooi.

NMe schreef op dinsdag 19 oktober 2010 @ 16:39:
[...]

Je hebt niet helemaal goed lopen zoeken denk ik. Dat die

ik krijg ook het ernstige vermoeden

directory op 777 staat wil niks zeggen, want als zo'n hacker geen fysieke toegang tot de server heeft kan hij hier niets mee, tenzij er een softwarematig lek aanwezig is die toegang op afstand mogelijk maakt. Als iemand om jouw beveiliging heen komt en dus in plaats van bijvoorbeeld een plaatje een PHP-script uploadt, dan is het hek van de dam. Die 777 van de map veranderen in 644 gaat dus het hackprobleem niet oplossen, je code goed beveiligen/indekken wel.

dat probeer ik natuurlijk zoveel mogelijk.. en volgens mij doe ik dat ook wel goed... wat dat betreft volg ik dit forum goed genoeg

[ Voor 51% gewijzigd door P.O. Box op 19-10-2010 16:42 ]

[OkkE]

P.O. Box schreef op dinsdag 19 oktober 2010 @ 16:40:
al mijn scripts zijn zelf geschreven.. dus een bekend lek kan het niet zijn

Met "bekend lek" wordt bedoelt "een veelgemaakte programmeerfout", zoals bijvoorbeeld user input niet escapen. Gezien de vragen die je hier stelt, zouden zulke er best nog wel eens ergens in kunnen zitten.

Verder als antwoord op je vraag: je kunt 777 gewoon gebruiken, maar check nog eens al je scripts, want er moet haast wel ergens een lek zitten.

[NMe]

OkkE schreef op dinsdag 19 oktober 2010 @ 16:43:
[...]

Met "bekend lek" wordt bedoelt "een veelgemaakte programmeerfout", zoals bijvoorbeeld user input niet escapen. Gezien de vragen die je hier stelt, zouden zulke er best nog wel eens ergens in kunnen zitten.

Verder als antwoord op je vraag: je kunt 777 gewoon gebruiken, maar check nog eens al je scripts, want er moet haast wel ergens een lek zitten.

Nou, die zou ook op elke willekeurige site op dezelfde server kunnen zitten, mits de beveiliging niet goed in elkaar zit. Maar ik kan me niet voorstellen dat een hostingbedrijf anno 2010 zijn server zo slecht beveiligt, dus ja: ergens wordt een upload niet goed gecheckt en kan een "hacker" code injecten.

[OkkE]

NMe schreef op dinsdag 19 oktober 2010 @ 16:50:
[...]

Nou, die zou ook op elke willekeurige site op dezelfde server kunnen zitten, mits de beveiliging niet goed in elkaar zit. Maar ik kan me niet voorstellen dat een hostingbedrijf anno 2010 zijn server zo slecht beveiligt, dus ja: ergens wordt een upload niet goed gecheckt en kan een "hacker" code injecten.

Oeps, mijn fout. Ik dacht gelezen te hebben "mijn server was gehacked", maar er stond "mijn website". Dan zou het inderdaad ook één van de overige sites op die hosting kunnen zijn.

Het zal je trouwens verbazen hoeveel (kleinere / goedkopere) hostingbedrijven nog slechte beveiliging hebben. Ben er het afgelopen jaar minimaal 2 tegengekomen, van de 10 denk ik.

[ Voor 6% gewijzigd door OkkE op 19-10-2010 16:56 ]

[P.O. Box]

hmm... ik check mijn userinput altijd, nou kan daar een fout in zitten natuurlijk, maar denk het niet... ik zal het checken...

ik zit niet bij de grootste provider van nederland, maar volgens mij wel gewoon bij een goede provider... hoe zou ik kunnen checken of mijn provider de boel niet goed beveiligd heeft?

[ Voor 3% gewijzigd door P.O. Box op 19-10-2010 17:02 ]

[Verwijderd]

P.O. Box schreef op dinsdag 19 oktober 2010 @ 17:01:
ik zit niet bij de grootste provider van nederland, maar volgens mij wel gewoon bij een goede provider... hoe zou ik kunnen checken of mijn provider de boel niet goed beveiligd heeft?

offtopic:
Mijn intuïtie zegt "door een hackpoging te doen". Vervolgens zegt de rest van m'n brein dat dat misschien een minder geslaagd idee is.

Maar alsnog de vraag aan de anderen in dit topic: wat is er niet mis met een world-writable directory voor uploads, terwijl veel hosters toch wel snappen dat de Apache-user in bijvoorbeeld een groep genaamd www-data hoort te zitten, om precies dit soort dingen te kunnen doen? Er zijn altijd genoeg te veel klierkoppen die denken dat het grappig is om je bestanden aan te passen als ze toch beschrijfbaar zijn.

[ Voor 8% gewijzigd door Verwijderd op 19-10-2010 17:23 ]

[mcDavid]

Behalve door lekken in je scripts, kan het inderdaad ook gewoon zijn dat hij je FTP-wachtwoord heeft achterhaald. Door het afluisteren van je verbinding of door spyware op je eigen computer. Dan zou dat "hacken" over moeten zijn met het wijzigen van je FTP-wachtwoord en het verzekeren dat je computer en je verbinding veilig zijn. En ook dit heeft weer niets met de rechten van de mappen te maken.

[NMe]

P.O. Box schreef op dinsdag 19 oktober 2010 @ 17:01:
hmm... ik check mijn userinput altijd, nou kan daar een fout in zitten natuurlijk, maar denk het niet...

Hoe precies check je je gebruikersinput en dan met name je uploads?

[Haranaka]

Opzich is er niets mis met een 777 directory om bv afbeeldingen in op de slaan. Wat ik persoonlijk doe is deze map vervolgens dmv .htaccess (644 (ervan uitgaande dat er geen suphp draait) ) beveiligen tegen het uitvoeren van scripts.
Mocht er toch een lek zitten in je eigen of 3rd party software dat ervoor zorgt dat kwaadwillende iets kunnen uploaden kunnen ze het vervolgens niet uitvoeren. Zo hou je bv een php script wat spam de wijde wereld in wil sturen toch nog tegen ondanks een eventueel lek in andere php scripts.

code:

# secure directory by disabling script execution
AddHandler cgi-script .php .php4 .php5 .php6 .pl .py .jsp .asp .htm .shtml .sh .cgi
Options -ExecCGI