Wat een prutsbedrijf. Weet niet eens welleke kleur hoedjes er gedragen werden.

Bekend is een groot woord. Het stond bijna een jaar in een niet gelezen issue-queue. Pas eind september was het lek "bekend" bij de relevante partijen.

PHP is, net als al het andere objectgeoriënteerd programmeren, gewoon veel te ingewikkeld voor stervelingen.
Over de implementatie van PHP & CMS wordt sowieso veel te makkelijk gedacht, en dan moet het er nog gelikt uit zien allemaal ook, dus wen er maar aan. :(

Kale HTML is inderdaad helemaal zo gek nog niet, tenminste, als je factoren als bedrijfszekerheid, benodigd onderhoud, robuustheid, controleerbaarheid, implementatietijd en vervangbaarheid meeneemt in je overwegingen.
Maar ja, "uitstraling," "dynamisch," "visie" en "interactief" en zo hé, het zijn nu eenmaal de frivole marketingjongens en -meisjes die vrijwel altijd het dichtste bij de beleidsmakers staan.

Nee, want we kennen je site niet.

Is er iemand hier die zelf een geinfecteerde site heeft gezien? Wat is er precies mee gebeurt?

Ik zie een handige flowchart in http://drupal.geek.nz/blog/your-drupal-website-has-backdoor om te bepalen of jouw Drupal site kwetsbaar is.

Uit de comments:
Meer goede info (zo te zien):
https://twitter.com/hashtag/drupalsa05
https://modulesunraveled.com/blog/how-restore-your-hacked-site
http://drupal.stackexchange.com/questions/133996/drupal-sa-core-2014-005-how-to-tell-if-my-server-sites-were-compromised/134501#134501

Nb. ik heb (gelukkig ;) totaal geen verstand van Drupal...

De RIG exploit toolkit kan CryptoWall installeren, zie bijv; http://sensorstechforum.com/remove-cryptowall-2-0-restore-encrypted-files/ (PS goed te zien dat er ook jongedames werken in de, helaas vooral door mannen bevolkte, securitywereld - en nee, dit is niet sexistisch bedoeld! Ik ben een aantal generaties verder 8-)

Weet iemand een goede Google dork voor compromised sites? Ik kan niks vinden.

Wat een amateurs allemaal. Wij hadden binnen een uur tijd met een drie man 250 individuele sites de fix meegegeven.

Als je er niet mee om kunt gaan, ga dan lekker weer HTML typen en laat de CMS'en aan de professionals over.

Dat je betaald wordt voor je werk is leuk, maar naar mijn nederige mening heb je pas recht op de titel 'professional' als je ook 'even' met 3 man een grondige audit doet van die 250 sites.
Het ergste vind ik nog wel dat je er van uit gaat dat er enkel sites gehackt zijn via scripting nadat die update is uitgerold, terwijl de achterdeur al een jaar open stond.


Ik weet niet wat ik jou allemaal wijs zou kunnen maken, maar als je de rest van m'n reactie nu niet moedwillig had verwijderd in je quote, had iedereen uit de context al op kunnen maken dat juist het tegenovergestelde waar is.
Bedankt voor het volledig onterechte compliment dat ik geen normale sterveling zou zijn ;)


Hahahahaha hoe ironisch; een framework zonder uitgebreide documentatie aanraden ivm veiligheid en dan de link nog foutief weergeven ook :p
Als je dan toch zelfstandig wil gaan prutsen met CMS op basis van een minder bekend framwework.., met alle nadelen van dien (support, documentatie, etc.).., zou ikzelf voor CodeIgniter kiezen.

Een behoorlijk objectieve vergelijking van de features bij (de minder bekende) frameworks: http://socialcompare.com/en/comparison/php-frameworks-comparison


Ik ben het vrijwel nooit met je eens, maar hiervoor krijg je zeker een dikke +1
Daarbij wens ik je ook veel succes met je site(s), ik ben blij dat jij het in ieder geval zo serieus op pakt!

Overgeneraliseren is ook een kunst. Het probleem van PHP is dat het een ongeorganiseerd zooitje is. Zo ook de "objectgeorienteerde" kenmerken; ze zijn later op de grote hoop van kenmerken en functies die PHP reeds vergaard had erbijgegooid. De structuur van PHP, of liever de schitterende afwezigheid hiervan, is wat het problematisch maakt als vehikel voor grotere projecten: Het zit gewoon veel te vol met afwijkingen, uitzonderingen, rariteiten, en wat dies meer zij. Er zit geen ontwerp en geen structuur in het geheel.

Dat gebrek aan eenduidigheid en de resulterende berg eigenaardigheden en bizariteiten in PHP is wat een hoge cognitieve belasting in het gebruik van PHP oplevert en dus evenzoveel minder ruimte laat voor de programmeur om nog greep en overzicht te houden op waar hij mee bezig is.

Ironisch genoeg is objectorientatie precies bedacht om te helpen cognitieve belasting te verlagen, en dat werkt ook prima zolang je je niet verliest in de meer esoterische constructen die onder deze noemer geschoven worden. Het kale idee van "object" als instantie van een "klasse" waarmee je een met duidelijke interactiecontracten omgeven verschillende delen van je programma kan afbakenen is vergelijkbaar met het idee van een "module", en zo gebruikt levert het een fijnkorreliger instrument om zulke scheidingslijnen door je programma te trekken.

Ga nu weer naar PHP kijken en zie dat ze wel het idee van een klasse gekopierd hebben maar heel die afbakening is een wassen neus, waarmee cruciale functionaliteit er gewoon niet inzit.


Heel het web is al jaren verleden verzand in wat ze nu "user experience" noemen, iets wat vooral ergernis oplevert als je niet met precies het juiste merk tablet met de juiste versie software in de hand van die gebruikerservaring komt genieten... op de voorgeschreven wijze.

Dat is niet heel flexibel, en ook al niet erg houdbaar. Het web is een gigantische zwerm eendagsvliegen geworden.

Kale HTML serveren, eventueel met wat CSS voor de aankleding, is prima te doen ook als je een CMS zou willen omdat er mensen zonder HTML-kennis de inhoud moeten leveren. Je moet dan je CMS zo opzetten dat de achterkant na het invoeren van nieuwe informatie een keer die HTML genereert en publiceert, waarna de bezoeker de gepubliceerde statische HTML geserveerd krijgt. Gezien de discrepantie tussen hoe vaak er nieuwe inhoud wordt toegevoegd en hoe vaak ze weer wordt opgeserveerd is het heel raar dat er niet veel meer systemen zijn die zo werken.

Zegt wel iets over het technische over- en inzicht bij de mensen die de beslissingen nemen maar ook die de websites bouwen. Je zou zelfs kunnen vermoeden dat het iets zegt over hoe PHP zo heeft kunnen worden als het geworden is.

De ervaring leert dat beveiligingslekken in PHP zelf de laatste jaren weinig worden gebruikt om in te breken. Het zijn voornamelijk PHP apps waarmee wordt ingebroken.

Dus het is niet gek om te zeggen dat je een veilige PHP app hebt, al wordt je daarbij ook geholpen als het aantal installaties laag is of als er nog geen exploits bekend zijn.

Overigens is de Java (die jij zo ruecksichlos propageert) een optie die ik zelf pas zou kiezen *na* PHP. Het is niet moeilijk raden waarom dat is. Tel het aantal Java lekken maar eens en de tijd die het kost om ze te dichten.