Dit is niet de eerste keer dat een CMS met een dergelijk patch-now-or-you-die komt. Wat hebben deze CMS'en gemeenschappelijk? PHP!

Ja, PHP super erg, de taal is de oorzaak van de vele bugs.
Ik Beheer een aantal CMS in JAVA en daar komen ook genoeg beveiligings problemen in voor, maar ja is close source en wordt door een selecte groep bedrijven gebruikt. Dus hoor je er niets over.

Ik kan je nog wat gemeenschappelijke punten melden:
1: Zijn allemaal OpenSource
2: Draaien bijna allemaal op Apache of Nginx (op Linux).
3: Gebruiken bijna allemaal MySQL of Mariadb als Database.
4: Gaat heel lang duren voordat alle installaties geupdate zijn.
5: Meest gehackte websites sites.

Mensen zoals jij die er totaal niks van afweten kunnen beter zwijgen.

Irrelevante punten want niet gerelateerd aan de patch-now-or-you-die voorvallen. Wat er duidelijk uitspringt is PHP. De thuissite hobbytaal van de scriptkiddie, die oneigenlijk wordt gebruikt voor 'professionele' sites.

Tja, closed source... Ja, zelfs in een professionele programmeertaal als Java kan je het goed verklooien! Maar dat ligt dan niet aan de kwaliteit van de programmeertaal maar aan de kwaliteit van de programmeurs. Waarschijnlijk PHP scriptkiddies die dachten dat ze ook wel in Java konden programmeren ;-)

Jij hebt er duidelijk de ballen verstand van. Wat jij feitelijk schrijft is dat als het in C, VBScript, C#, ASP, etc geschreven was er onmogelijk een bug in zou kunnen zitten die als security issue aangemerkt kan worden?

Of zou het dan toch heel misschien gewoon menselijk falen zijn dat onafhankelijk van de gebruikte taal voor kan komen?

Ha, ha, VBScript. En je vergeet Java. Nee, ik schrijf dat de kans hierop véél groter is als je met slecht, amateuristisch gereedschap werkt!


Uiteindelijk is het allemaal menselijk falen. Maar als je al van start gaat met een foute keuze en PHP als gereedschap gaat gebruiken, tja, dan ben je echt kansloos bezig. Natuurlijk maakt het gereedschap wat je gebruikt erg veel verschil! Als je dat niet gelooft dan stuur ik een professionele timmerman bij je langs die jouw dak komt aanleggen met een houten hamertje dat hij in een kinderspeelgoedwinkel heeft gekocht. Heeft echt geen invloed op de kwaliteit van je dak hoor! Beloofd! Echt niet!

En kan je je standpunten ook onderbouwen? Leg op zijn minst eens uit waarom je van mening bent dat PHP amateuristisch is. Je geroeptoeter is momenteel niets meer dan een slechte troll.

Een goed team met matige hulpmiddelen komt tot veel betere resultaten dan een matig team met goede hulpmiddelen.

Dat zeg ik op basis van een kwart eeuw automatiseringservaring met meestal helemaal niet zo geweldige hulpmiddelen. Ik heb niet met PHP gewerkt, maar wel met verschillende closed source-platforms die ook vol zaten met tenenkrommende inconsistenties en ontwerpfouten die je soms deden afvragen of er überhaupt wel een ontwerp aan ten grondslag lag. Dat daar toch robuuste systemen mee te bouwen waren komt omdat je als programmeur haarfijn doorkrijgt hoe al die inconsistente features zich precies gedragen, welke je moet mijden als de pest en hoe je de rest moet gebruiken zonder dat ze ongelukken opleveren.

Het is zeker niet ideaal, maar een goed team leert wel met die matige hulpmiddelen omgaan, terwijl een matig team echt niet gered wordt door goede hulpmiddelen.

(Met een goed team bedoel ik trouwens niet dat dat uit alleen maar toppers bestaat, ik heb juist vooral uitstekende ervaringen met teams die heel divers waren in de aanwezige talenten en niveaus. Essentieel is dat ze met elkaar en de opdrachtgever kunnen samenwerken, dan komen die talenten tot uiting in het resultaat.)

Zo zie jij het. Maar het is exact het zelfde argumenten. Ze passen alleen niet in jou denk beeld voor jouw statement. Maar het klopt wel. Maar mijn punten zijn exact de zelfde onzin als dat jij meld.

Mensen, graag een verzoek om niet meteen al vechtend over straat te rollen bij een discussie op dit forum.
Laat elkaar a.u.b. in waarde en kom met argumenten. Daar heeft iedereen wat aan.

Jaaa... Je kan best een heel eind komen met zo'n speelgoedhamer ;-)

Heb je door dat je niets zegt?

@Krakatau Maar wat gebruik jij eigenlijk? Welke taal en tools?

Ik wil aan de PHP-haters op dit forum vragen eens man en paard te noemen. Wat precies is er nou zo onveilig aan PHP?

Zelf vind ik PHP rommelig en werk er niet graag in (een heel verschil met Python). Maar om te zeggen onveilig, dat nou ook weer niet. PHP heeft een uitgebreide encryptie en hashing bibliotheek, allerlei tools om inputs te cleanen en binding van SQL statements om SQL injections tegen te gaan. In elke taal is het wijs om input op limieten en speciale tekens te controleren, zo ook in PHP.

Misschien vinden de PHP-haters dat PHP programmeurs onervarener (of luier) zijn dan Java en Python programmeurs? Is dat het?

Zie: https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet#Language_issues

Toevoeging voor de volledigheid: ik heb ook meegemaakt dat teams die met state-of-the-art hulpmiddelen werkten, high-end ontwikkelplatforms zoals Visual Studio .NET met alles erop en eraan bijvoorbeeld, met daarin ervaren ontwikkelaars die neerkeken op die achterhaalde "speelgoedhamers", om een term van Krakatau te lenen, eindeloos lang deden over vrij basale systeempjes die met die "speelgoedhamers" al lang en breed klaar en operationeel zouden zijn, die dan ook nog eens schokkend slecht bleken te implementeren waar gebruikers om gevraagd hebben en al even slecht in staat bleken de vereiste gegevensuitwisseling met de aanwezige systemen te doen. Tot overmaat van ramp waren de eerste versies ook nog eens niet vooruit te branden. Het enige dat voor die systemen sprak was dat ze er gelikt uitzagen. Daar heb je alleen niet zo veel aan als ze niet doen wat ze moeten doen.

Dat bedoel ik als ik stel dat matige teams niet door goede hulpmiddelen gered worden. Met ontwikkelaars die zichzelf behoorlijk superieur vonden omdat ze dachten dat de weg kennen in het geavanceerde platform-du-jour het hele eieren eten is en belangrijker is dan bijvoorbeeld begrijpen wat je gebruikers willen, maar dat terzijde. Goede teams met matige hulpmiddelen hebben dan echt mijn voorkeur daarboven, en goede teams met goede hulpmiddelen zijn natuurlijk ideaal. Maar die luxe krijg je niet altijd.

Met een speelgoed hamer kan je best goed werk afleveren.
Met een professionele hamer kan je ook een hoop prutswerk afleveren.

Het hangt allemaal af, van de persoon die de hamer gebruikt, het is maar een doel om het eind resultaat te bereiken.

Duidelijk geen verstand van software development.

https://blog.codecentric.de/en/2008/07/comparison-of-java-and-php-for-web-applications/

Waar iemand programmeert worden fouten gemaakt (Apache Tomcat CVE's anyone?!?).
Elke taal heeft voor en nadelen. Hou toch op.

Java, twee jaar lang verbannen van deze site omdat zijn eindeloze pro java trolling rants compleet de spuigaten uitliepen.
En nu na een paar maandjes weer opnieuw van de partij begint het stilletjes aan weer opnieuw onder excuus van aanval op php.
Bekijk de kwartaal patches en de cve jaarlijsten met severe gaten in java en je begrijpt dat hij zich beter bezig kan houden met zijn eigen brakke slecht en vaak laat gepatchte spullen op orde te houden.

Leuk geprobeerd maar ik ben nooit verbannen geweest van deze site. En ook nooit weggeweest. En over welke Java trolling rants heb je het eigenlijk?


En nu na een paar maandjes weer opnieuw van de partij? Zojuist was het toch twee jaar? Best moeilijk hè, de lijn van je eigen betoog vasthouden. Zo van de ene zin naar de andere.


De 'severe' gaten in Java? Dan heb je het over het hele Java platform? Of over de Java webbrowserplug-in? Wat je dan ook denkt te bedoelen, feit is dat ik nog nooit heb gehoord van dit soort patch-now-or-you-die toestanden bij Java of ASP .NET.

Onzin natuurlijk! Een houten speelgoedhamer is geen vervanging voor echt en goed gereedschap. Als je weet waarover je praat dan is het overduidelijk dat je PHP niet kan vergelijken met echte programmeeromgevingen (zoals o.a. Java en ASP .NET).

Check het jaartal.

Doei!

Ergens in 2015 ben je van deze site gegooid, alle posts zijn verwijderd in twee stappen.
Behalve de posts die waren gequoted.
filter zelf maar op voor 2016

Tussentijds heb je sporadisch anoniem gepost met klachten over je verwijdering
en ondertekend met krakatau.
Niet iedereen is malloot hier.

Blijkbaar wel:

a) destijds heb ik zelf mijn account verwijderd uit onvrede met de vele malloten hier op de site (uitzonderingen nagelaten);
b) ik heb nooit anoniem geklaagd over mijn 'verwijdering' (want ik ben nooit verwijderd; doet http://security.nl dat überhaupt met accounts?);
c) enige tijd later heb ik nieuwe accounts genomen en ben daarmee steeds aanwezig geweest op deze site;
d) je account verwijderen en daarmee al je posts kan tegenwoordig geloof ik niet meer dus de kans dat deze geschiedenis zich herhaalt is klein (hoewel - het is natuurlijk niet zoveel moeite om zelf even een programmaatje te schrijven dat al je posts één voor één verwijdert - en daarna handmatig je account te verwijderen).

Ach, er is ook zóóveel veranderd aan PHP sinds 2008 ;-)


a.k.a. 'scriptkiddies'.


Seasoned and professional developers in Java.


a.k.a. bij elkaar gehackte rotzooi.

En niet één on-topic reactie m.b.t. het onderwerp van het artikel, beetje jammer.

Eens.
- In alle software zitten fouten.
Door wie en het hoe en waarom bij het voorkomen is niet een coderings dan wel programma-taal probleem meer iets van benodigde rijd met de ervaring om een logisch probleem goed vertaald te krijgen naar techniek.
- Elke fout hoe klein ook kan uiteindelijk tot een ernstig probleem leiden
Het beste is een ontwerp met meerdere veiligheden ringen van kwetsbaarheid en impact.
- De "mythical man month" geen het project management probleem aan. Het moet op tijd tegen zo laag mogelijk kosten.
Het "swing tree" plaatje is een goed referentiekader van de dagelijkse praktijk al meer dan 35 jaar.

Alleen nerds die vastzitten in een techniekje gaan tekeer over techniek.
Zeer storend, ze veroorzaken daarmee nog meer problemen in onderlinge afstemming en het uitdragen wat nodig is.

Alleen volidiote digibeten verwachten met een houten speelgoedhamer (PHP) kwalitatief goed werk te kunnen leveren.


Je zal merken dat programmeurs die met echte programmeertalen werken ook beter in staat zijn om goede ontwerpen voor hun software te maken.


http://i3.kym-cdn.com/photos/images/newsfeed/000/475/749/fd8.jpg

Leuk maar duidelijk een gevolg van veel te veel lagen (mensen; management lagen) tussen requirements en implementatie. Een klant die direct met het ontwikkelteam communiceert, waarbij via prototyping echte duidelijkheid in de requirements wordt verkregen is vaak het effectiefst.


Alleen digibeten blijven zich op zeer storende wijze verzetten tegen de open deur dat het gereedschap wat je gebruikt wel degelijk een grote invloed heeft op de kwaliteit van je resultaat.

Ik stam uit de tijd dat je het gehele speelveld moest beheersen hardware, software en de klantvraag. Prachtige projecten in die tijden gedaan als je dat achteraf bekijkt. https://en.wikiquote.org/wiki/Edsger_W._Dijkstra Dat was een van de personen lees even de epsitels en begrijp zijn ideeën. Dan kun je zien welke onzien je hier aan het posten bent dat de programmeertaal leidend is. Jij hebt net hem en veel van de mensen die het vak opgebouwd hebben als digibeet weggezet.

Je moet het wel eerst goed aanleren, daarna kun je het zelfs in machinecode neerzetten ofwel zelf de compiler nadoen. Dat laatste is vooral nodig in green area's en niet voor groentjes weggelegd. Structured programming is prima door alle lagen door te zetten zelf als je niet eens een programmeertaal gebruikt.

Het geld en de budgetten worden in de organisatie bepaald, dat is een gegeven waar je het mee moet doen.
Alleen de thuishobbyist dan zel zzp ondernemer heeft geen organisatie vraagstukken wel de budgetvraag.
De https://en.wikipedia.org/wiki/The_Mythical_Man-Month is op dezelfde basis en waarneming APL (ooit een programmeertaal) Algol er geen "silver bullet". Dat de ICT telkens de zelfde fouten blijft herhalen en voorspelbaar (defined) is wel en managed als CMM level https://en.wikipedia.org/wiki/Capability_Maturity_Model is een prachtige 4 uit 5. Niet helemaal de intentie van CMM maar dat is wat anders.

Een klant die direct met het ontwikkelteam communiceert gaat voor het snelle goedkope resultaat. Dat heeft gewoonlijk als gevolg een grote chaos in de shadow ict met zee gebrekkige structuur en slecht veiligheid. Dank voor je positionering in deze, het schetst jouw wereldje.

Als er iets is wat jij hier hebt duidelijk gemaakt, karma4, is dat jij niet degene bent die het hele speelveld overziet en beheerst. Je demonstreert keer op keer een consequent onvermogen om de techniek te begrijpen en de enige die jouw prestaties als geweldig ervaart ben jij zelf.


Edsger W. Dijkstra heeft o.a. gezegd:

More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages.

Dat klinkt toch niet echt alsof hij vond dat je met eender welke programmeertaal maar aan de slag moest gaan.

Ik stel dat het gereedschap wat je kiest wel degelijk een grote invloed heeft op het eindresultaat. Bij grotere en complexere problemen kan je met ongeschikt gereedschap geen kwaliteit meer afleveren. De beperkingen van het gereedschap gaan je in de weg zitten, waardoor er bij het corrigeren van het ene steeds het andere omvalt. Door beperkingen van het gereedschap kan je deelproblemen niet wegabstraheren, waardoor ze steeds de kop blijven opsteken.


Gezwam van een wannabe... Heb je enig idee hoeveel 'regels' code die (zinloze) aanpak zou opleveren en hoeveel fouten daar dan in zouden zitten?


Arme karma4 met z'n goedkope en sullige suggestieve in-een-hokje-plaatsen mentaliteit :-) Ik heb jaren in een CMM Level 3 organisatie (of was het nou level 2 met traject richting level 3?) gewerkt. En de bijbehorende cursussen gevolgd. Ik weet dus uit eigen ervaring dat dit soort dingen niet echt werkt en voornamelijk managers een (helaas onterecht) goed gevoel geeft.


Arme karma4 met z'n goedkope en sullige suggestieve in-een-hokje-plaatsen mentaliteit :-) Je weet toch hopelijk wel dat NASA al geruime tijd met agile methodes werkt? (En what's good enough for NASA...)

Development Team / Customer Interaction
With a short delivery cycle, the availability of working code for evaluation and feedback, makes it possible to have closely coupled interactions between the development team and the customer. The developer-customer interaction is very useful to verify new features as they are rolled out.

https://www.projectmanagement.com/blog-post/33661/Agile-NASA-software---Are-you-Crazy---