Code review, iemand huren of ...

[azerty]

Op dit moment ben ik een CMS systeem van de grond aan het opbouwen, met als voornaamste bedoeling veel bij te leren*, maar ook om dit in te zetten voor de paar sites die ik moet onderhouden.

Omdat ik dit dus publiek wil inzetten, moet de code die ik nu aan het schrijven ben dus veilig zijn, en niet zo lek als een zeef... Hij moet dus door een externe persoon nagelezen worden, bij voorkeur iemand die er wat ervaring mee heeft.

Dit zorgt dus voor (ik als student zijnde) dat 99.5% van de mede lln. al uit de boot valt, zij hebben namelijk nog maar een basis van php gezien, en zeker al niets rond beveiliging ervan.

Ik vraag me dus af, als ik de code wil laten reviewen op mogelijke fouten, hoe ik dit het best aanpak? Ik zie op dit moment de volgende opties:

- Iemand kunnen inhuren: dit kost geld, en ik vraag me dan af hoe ik garantie krijg dat de ingehuurde persoon daadwerkelijk de moeite doet om fouten op te sporen?

- De code op github/consorten publiceren en open-bron maken. Dit kost niets, en als er mensen geïnteresseerd zijn kunnen ze de code zelf nalezen (en fouten aan het licht brengen), maar iemand die iets kwaads in zin heeft kan dit natuurlijk ook uitbuiten.

- Een medestudent de code laten lezen: zoals hierboven aangehaald is er weinig kans dat hij er een fout zal uithalen, en de interesse hiervoor is waarschijnlijk ver te zoeken

Zijn er mensen die hier gelijkaardige ervaring mee hebben of die tips hebben om dit "probleem" aan te pakken?

* Geen opmerkingen over hoe nutteloos dit is aub, het is om bij te leren, en als ik het dan toch heb, kan ik het evengoed gebruiken ^^

[ Voor 4% gewijzigd door azerty op 03-05-2012 23:24 ]

[Avalaxy]

Tja... Niet je eigen CMS maken, simpel. Ik snap honestly niet waarom iedereen continu het wiel opnieuw aan het uitvinden is.

Ik denk dat je het met een eigen brouwsel qua features, support en veiligheid gewoon nooit gaat halen bij de bekende pakketten, zeker niet als je nu al twijfelt.

[azerty]

Het is vooral om bij te leren dat ik het doe, en als er dan nog eens iemand de code overleest en mij op andere fouten wijst die ik over het hoofd zou zien, leer ik nog meer bij.

Nu goed, laat ik dan de vraag bijschaven tot:

Als ik software schrijf op mijn eentje (niet-commercieel) en ik wil dit laten nalezen op fouten, welke van de bovenstaande suggesties is dan het beste?

[Kuhlie]

Je medestudenten betalen per gevonden bug die exploitable is? En/of idem-dito met je gehuurde persoonprofessional.

(Los van dat ik het eens ben met dat je zelf niet het wiel moet uitvinden )

[ Voor 4% gewijzigd door Kuhlie op 03-05-2012 23:22 ]

[Gamebuster]

Gewoon gebruiken. Zorg voor een goed updatebaar en onderhoudbaar systeem. Eventuele beveiligingslekken kom je hopelijk nooit te weten. Als je veel logt, errors niet zichtbaar maakt voor gebruikers en errors via mail naar je toe laat sturen, kom je al veel te weten.

Eventuele hack-pogingen gaan vaak vooraf met een lading foutmeldingen bij pogingen tot SQL injection en dergelijke. Als je bij fouten een mail ontvangt, wordt je gewaarschuwd. Uit recente praktijk ervaring kan ik je zeggen dat dit zeer nuttig is, gezien er veel geautomatiseerde hack-tools het internet rond dwalen en random sites "testen".

Avalaxy schreef op donderdag 03 mei 2012 @ 23:17:
Ik denk dat je het met een eigen brouwsel qua features, support en veiligheid gewoon nooit gaat halen bij de bekende pakketten, zeker niet als je nu al twijfelt.

Dat zal nog vies tegenvallen. Bekende pakketten hebben ook bekende beveiligings-problemen. Een degelijk beveiligd eigenbouw systeem is naar mijn mening/ervaring veiliger dan een kant en klaar open-source pakket. Niet omdat het persee beter beveiligd is, maar omdat de eventuele beveiligings-lekken niet bekend zijn op internet en beter bekend zijn bij jou.


Ik zou het ook niet "het wiel opnieuw uitvinden" willen noemen. Het is niet alsof hij opnieuw een CMS uitvindt. Hij schrijft alleen een nieuwe implementatie, net zoals er 1000en merken en soorten wielen en banden zijn. Leerzaam en indien goed uitgevoerd werkt het beter dan zo'n standaard pakket. Je hebt er immers volledige controle over en het doet daarom precies wel en niet wat jij wel en niet wilt.

[ Voor 16% gewijzigd door Gamebuster op 03-05-2012 23:29 ]

[azerty]

Kuhlie schreef op donderdag 03 mei 2012 @ 23:22:
Je medestudenten betalen per gevonden bug die exploitable is? En/of idem-dito met je gehuurde persoonprofessional.

(Los van dat ik het eens ben met dat je zelf niet het wiel moet uitvinden )

Dat is inderdaad een optie die te overwegen is, dat had ik nog niet echt overwogen.

off-topic: natuurlijk is het in zeker mate nutteloos, maar dat zijn alle oefeningen die je in school maakt ook vanuit dat standpunt. Heb mijn originele post aangepast, zoals oorspronkelijk gezegd is het om bij te leren, maar als ik dat werkend cms dan toch heb, kan ik evengoed de huidige sites overzetten.0. En omdat een site toch geregeld veranderd, sluit niets uit dat ik dan na verloop van tijd overschakel naar een bestaand platform, alhoewel er daar natuurlijk ook altijd fouten inzitten...

Gamebuster schreef op donderdag 03 mei 2012 @ 23:25:

Gewoon gebruiken. Zorg voor een goed updatebaar en onderhoudbaar systeem. Eventuele beveiligingslekken kom je hopelijk nooit te weten. Als je veel logt, errors niet zichtbaar maakt voor gebruikers en errors via mail naar je toe laat sturen, kom je al veel te weten.

Eventuele hack-pogingen gaan vaak vooraf met een lading foutmeldingen bij pogingen tot SQL injection en dergelijke. Als je bij fouten een mail ontvangt, wordt je gewaarschuwd. Uit recente praktijk ervaring kan ik je zeggen dat dit zeer nuttig is, gezien er veel geautomatiseerde hack-tools het internet rond dwalen en random sites "testen".

*snip*

Bedankt voor je visie hierop, dit was een ander gedacht van mij, maar omdat ik toch liever voorkom dat er überhaupt lekken in zouden kunnen zitten leek het mij nuttig hier toch eens advies te vragen

Het is echter wel de bedoeling dat fouten goed afgevangen worden, en dat er een goed log-systeem is. Maakt deel uit van het leerproces

[ Voor 36% gewijzigd door azerty op 08-11-2014 23:58 ]

[Freeaqingme]

Ik ontving laatst een mailtje waarin eerst mijn skills opgehemeld werden, om vervolgens te vragen of ik een review wou uitvoeren van een niet nader te noemen foss kansloos cms. Uiteindelijk bleek deze persoon het CR-Team van het Zend Framework gespamd te hebben.

Ik kan je 1 ding aanraden: doe dat niet. Het leverde een hoop negatieve publiciteit op (op twitter), het github account van die persoon werd geblokkeerd, en mijn ego werd alleen maar groter :wink:.

Hoe dan wel? Je kan een security audit laten uitvoeren door een bedrijf wat hierin gespecialiseerd is. Is wel leuk, allicht leerzaam, maar dan ben je dubbel zo lang bezig je studieschuld terug te betalen. Als je je medestudenten ook niet zo ver kan krijgen, zou ik gewoon nog een goed boek lezen over security als ik jou was, om vervolgens zelf je applicatie heel kritisch na te lopen. Daarnaast, als je gewoon kritisch op jezelf bent tijdens developen kan je al heel veel ondervangen. _altijd_ user input escapen, ook als dat in een database was opgeslagen. Waar nodig CORS gebruiken, rekening houden met CSRF, en altijd _alle_ input naar je database escapen (tip: gebruik gewoon overal prepared statements, al dan niet via een dbal). Daarnaast uiteraard _overal_ dezelfde character en encoding gebruiken: in je formulieren, expliciet in je php code dmv mbstring, in je connectie naar je RDBMS, in je RDBMS zelf, in je uitgaande headers, in je (x)html, etc.

[azerty]

Freeaqingme schreef op vrijdag 04 mei 2012 @ 00:22:
*snip*

Bedankt voor deze info. Sowieso was het niet de bedoeling bij het open-bron maken van de code om hier dan verschillende mensen voor te contacteren, maar om dit zijn eigen gang te laten gaan.

Nu ja, met jouw reactie en die van GameBuster denk ik dat ik voor het gewoon publiceren zal gaan, nadat ik de code op het einde zelf nog eens goed doorlopen heb, en ervoor gezorgd heb dat ik een goed log-systeem op poten heb staan.

Bedankt!

[Kalief]

Zoek een sponsor. Een softwarebedrijf dat voor een vermelding als tegenprestatie wel je code wil nakijken.

[DEiE]

Voor kleine onderdelen zou je ook http://codereview.stackexchange.com/ of http://www.reddit.com/r/reviewmycode kunnen overwegen. Voor het gehele systeem is dat natuurlijk niet te doen, maar voor kleine dingen als correct verbinding maken met een database om maar even iets te noemen is het wel geschikt.

[jostefa]

Zorg dat je CMS alleen bereikbaar is vanaf bepaalde ip adressen

[Gwaihir]

Kuhlie schreef op donderdag 03 mei 2012 @ 23:22:
Je medestudenten betalen per gevonden bug die exploitable is? En/of idem-dito met je gehuurde persoonprofessional.

En kijk of er geen vak op je opleiding is wat over het vinden van dit soort issues gaat. Zo ja, kijk of het daar uitgeplozen kan worden, als onderdeel van dat vak.

(Los van dat ik het eens ben met dat je zelf niet het wiel moet uitvinden )

Oftewel.. je zou ook op een bestaand CMS iets nuttigs bij kunnen bouwen. Pak iets van hoog op de wensenlijst van je favoriete open source CMS, bouw het en lever het aan het project aan. Dat zal absoluut wél serieus uitgeplozen gaan worden en je flink feedback opleveren. Lijkt me wel zo leerzaam ook.

[Grijze Vos]

Een eigen cms bouwen is ontzettend leerzaam. Ja, je moet het niet in productie gooien op tig sites, maar je kunt er best een hobbyproject mee runnen. Ik snap neit waarom iedereen hier daar zo op tegen is.

Het is niet iemand die voor zijn werk een site forum neerzet, het is iemand die iets bij wil leren over de technieken.

[Martijn19]

Mwah, ik zal je code helemaal niet laten reviewen, tenminste niet er voor betalen. "Vroeger" keek ik wel eens op Phpfreaks.com, daar was ook een gedeelte waar je je script kon laten nakijken (zonder garanties uiteraard)
Als je zelf een beetje bekend bent met best security practises en als de sites die op jou CMS gaan draaien geen gevoelige informatie hebben dan zie ik geen kwaad in om de boel online te gooien.
Wat ik _niet_ zou doen, is je eigen 'leer-cms' voor klanten inzetten. Klanten willen op een gegeven updates en veranderingen en als jij een eigen CMS in je eentje moet onderhouden gaat daar véél tijd inzitten.

Zelf ben ik overigens wel fan van www.pyrocms.com als CMS waar ik wel eens custom made addons voor maak.

[Verwijderd]

Ik loop tegen hetzelfde "probleem" aan. Heb vorig jaar mijn eigen CMS geschreven in PHP en doe nu hetzelfde in Ruby On Rails. Net zoals jij doe ik dit vooral om veel bij te leren maar wanneer iemand een nieuwe site nodig heeft aarzel ik niet om mijn cms te gebruiken.

Op Stackoverflow is trouwens ook een leuk draadje te vinden ivm security: What should evey programmer know about security

[azerty]

Bedankt voor de antwoorden in tussentijd!

Ik herken me ongeveer volledig in jouw reactie Rubinski, het is inderdaad om bij te leren, maar eenmaal het er is is het dan ook "zonde" om het niet te gebruiken in de paar (amateur)sites die ik moet beheren. Er zitten geen professionele klanten tussen (mijn vader en nog een broer van een vriend) die niet echt veel eisen stellen. Bovendien is het (hoop ik toch ) zodanig opgebouwd dat een wijziging uiteindelijk niet zoveel werk inhoud.

Ik ga dus deze zomer (de examens komen er ondertussen al weer aan) de code zelf nog eens goed nalezen, en aan een paar medestudenten vragen (als ze interesse hebben) om het ook na te lezen/ proberen in te breken en dan online maken.