Beveiliging van geüploade bestanden

Status
Niet open voor verdere reacties.

CWhore

Gebruiker
Lid geworden
4 nov 2005
Berichten
99
Beste forumgenoten,

Als onderdeel van een te bouwen systeem voor financiële gegevens heb ik een uploadscript gebouwd. Met dit script worden financiële gegevens geüpload en naar de database weggescreven. Echter wil ik de originele upload op de server bewaren, zodat de gebruiker nog kan zien wat hij/zij destijds heeft geüpload.

Voor elk bestand dat is geüpload, wordt een random map op de server aangemaakt met de 777 chmod rechten. Kortom: elk bestand staat in één mapje (met als naam bijv. 109bdg5h6d) en elk mapje bevat één bestand (ook met een random naam, bijv. 3492834.xls).

Hoe realistisch is het dat iemand van buitenaf erachter komt hoe de map/bestandsnamen heten? Zijn er bijvoorbeeld via de browser technieken om erachter te komen welke mappen er op de server staan?

Ben benieuwd! Veiligheid van gegevens is immers erg belangrijk.


Met vriendelijke groet,
Arno
 
Aangezien we de rest van het systeem niet kennen is het onmogelijk te zeggen hoe realistisch dat is.

Maar zodra ik chmod rechten van 777 zie beginnen mijn nekharen te rijzen.
waarom zou je de eigenaar, de groep en ieder ander lees schrijf en uitvoer rechten geven op een map op je server.

In combinatie met een upload script zie ik wel kansen om je systeem flink om zeep te helpen. (mogelijk script uploaden die je uitvoert)

je hebt het over terugzien van een upload door de gebruiker.
- waarom moet hij dat kunnen?
je zet de gegevens in de database dus van daar uit kan hij het ook controleren.
eventueel in het geval van vraagtekens zou een beheerder (manager/whoever) de upload erbij kunnen halen voor vergelijk.

Moet het toch kunnen?
Lezen is dan voldoende, wijzigen en uitvoeren niet dus is 777 niet nodig en zou 400 voldoende kunnen zijn (eigenaar van het bestand kan lezen, de groep en de rest niets)
 
Beste Ellasar,

Bij het uploaden, moet ik een map aanmaken met 777 rechten om het te uploaden bestand erin weg te kunnen schrijven. Ik heb nog even nagedacht, en de gebruiker hoeft het originele bestand inderdaad niet meer te kunnen zien. Voor de beheerder zou het echter wel handig zijn als er zich fouten voordoen bijvoorbeeld.

Wellicht is het dus een optie om na het uploaden via PHP de desbetreffende map 000 rechten te geven?

Je geeft aan dat 400 rechten ook voldoende zijn, wie of wat wordt er dan precies onder 'de eigenaar' verstaan? De server of een script dat op de server staat?

Weet je toevallig ook hoe realistisch is het dat iemand van buitenaf erachter komt hoe de map/bestandsnamen heten? Zijn er bijvoorbeeld via de browser technieken om erachter te komen welke mappen er op de server staan? (afgezien van het feit of die mappen 000 of 777 rechten hebben?)

(Alvast) bedankt voor je reactie!
 
Hoi CWhore,
Zijn er bijvoorbeeld via de browser technieken om erachter te komen welke mappen er op de server staan? (afgezien van het feit of die mappen 000 of 777 rechten hebben?)
  • Kijk, zo kom je bijvoorbeeld in 0.05 sec. al een heel eind... ;)
Maar als je een stevig beveiligd login-systeem hebt om de betreffende database te bezichtigen (uploaden enz. via https enz.), en/of de geheime mappen bij directe toegang via .htaccess doorsluist naar een melding "404 - Page Not Found" (i.p.v. "Access Denied"), is dat niet genoeg?
Of daarbij als beheerder die database met geüploade gegevens wekelijks downloaden naar een locale machine, om vervolgens de database leeg te stofzuigen, zodat er helemaal niets aan gegevens meer in de cloud rondzweeft? - Of meteen na een automatisch mail-alert?
Of een tunnel-systeem voor het heen-en-weren van gevoelige info, of op een andere manier de data eerst laten versleutelen alvorens het uploaden plaatsvindt?
- En iets heel anders, als ik zo de omvang van het bedrijf zie: is het niet een idee om een gespecialiseerd ICT-beveiligingsbureau in de arm te nemen?

Met vriendelijke groet,
CSShunter
 
Laatst bewerkt:
Beste CSShunter,

Bedankt voor je reactie!

Ik lees vele mogelijkheden om de files te beveiligen. Ik ga er binnenkort naar kijken. De oplossing staat er in ieder geval tussen!

Wat betreft dat 'even iets anders' - het te ontwikkelen systeem is niet voor het bedrijf waar jij aan refereert. In dat geval zou daar inderdaad een automatiseringsbedrijf voor worden ingeschakeld.

Anyway, ik zal het topic even sluiten omdat er genoeg oplossingen voorhanden zijn. Bedankt allemaal!
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan