WordPress dicht 'kritiek' xss-lek

WordPress heeft een nieuwe versie uitgebracht waarin onder meer een 'kritiek' beveiligingslek is opgelost. Het lek werd gevonden door een Belgische beveiligingsonderzoeker. Ook twee kleinere beveiligingsproblemen zijn opgelost.

Het lek is volgens het ict-beveiligingsteam van de Amerikaanse overheid dermate gevaarlijk dat website-eigenaren het best zo snel mogelijk kunnen updaten naar een nieuwe versie van WordPress. Alle installaties tot en met 4.1.1 zijn kwetsbaar; versie 4.1.2, die deze week is uitgebracht, lost het probleem op.

Het lek in WordPress werd ontdekt door de Belgische beveiligingsonderzoeker Cedric van Bockhaven. Hij ontdekte dat WordPress een cross site scripting-kwetsbaarheid bevat, waarmee aanvallers eigen html- en javascript-code kunnen toevoegen aan een website. In dit geval zou een aanvaller daarmee een site kunnen overnemen.

Daarnaast zijn in WordPress twee kleinere bugs opgelost, die kleinere kwetsbaarheden dichten. Daarbij gaat het onder meer om een minder gevaarlijk xss-lek. Ook waarschuwt WordPress ervoor dat veel ontwikkelaars van plugins de afgelopen dagen updates hebben uitgebracht, en dat beheerders van websites die het beste ook kunnen updaten. Het gebeurt vaak dat WordPress-plugins kwetsbaar zijn voor aanvallen.

Reacties (84)

[Ebel87]

Versie 4.2 van Wordpress is uit

https://wordpress.org/news/2015/04/powell/[/b]

[Reactie gewijzigd door Ebel87 op 22 juli 2024 15:14]

[CH4OS]

Overigens is inmiddels ook alweer Wordpress 4.1.3 uit, die later uitgebracht is dan 4.2. 4.1.3 lekt een ander lek uit 4.1.2, geen idee of die ook in 4.2 zit.

[Verwijderd]

Elke keer als ik zoiets lees denk ik, waarom leer je niet gewoon websites maken en bouw je zelf een CMS? en even ter info, door zelf een CMS te maken ben je minder snel target omdat ze geen toegang hebben tot jouw code en daarom dus niet snel dingen kunnen vinden.

Andere voordeel is, wordpress sites herken je snel wp_ in de sourcecode, waardoor je bv snel target bent dmv bepaalde bugs.

Dit heb je niet als je zelf je dingen maakt.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:14]

[happyguppy]

Je slaat compleet de plank mis.

Open source software is niet per definitie minder veilig of veiliger dan je eigen geschreven spul. Je hebt veiligheid grotendeels (bijv. dus bij Wordpress projecten) zelf in de hand door goede installatie protocollen en checks.

Als je zelf dingen maakt dan is het wellicht minder gemakkelijk om via bekende wegen in je site te komen; maar het team dat achter Wordpress zit fixed meer van dit soort issues dan je ooit zelf zou kunnen doen. Je kunt een Wordpress installatie ook zo opzetten dat het aan de voorkant (en zelfs de broncode van die voorkant) van de site compleet onduidelijk is dat WP erachter zit.

En, als je dan toch ergens op zoekt; dan zal het niet wp_ zijn (dat is de standaard database tabel prefix, maar als je veiligheid serieus neemt dan gebruik je die toch niet). Ik denk dat je verwijst naar wp- (wp-content, wp-admin, wp-includes). Veelal gebeuren de hacks via scripts die op dit soort strings checken; waarna ze bij een positief resultaat bekende bugs proberen te exploiteren.

En nee; als je je thema's en plugins op de voorgeschreven manier ontwikkeld; dan gaat er niets stuk bij een (automatische) update.

Naast de groep mensen die voor een custom Wordpress site gaan is er natuurlijk een grote markt voor mensen die geen technische kennis hebben, maar toch een website willen die ze relatief gemakkelijk in elkaar kunnen zetten. Wordpress is daarvoor een bijna-perfecte oplossing, en de updates helpen daar natuurlijk alleen maar in mee.

[Reactie gewijzigd door happyguppy op 22 juli 2024 15:14]

[maartenvdezz]

True, maar tegelijkertijd zal er meer tijd gestoken worden door een veel grotere groep hackers om een lek te vinden (vergelijkbare situatie als met Windows).

[happyguppy]

Eensch; het gaat beide kanten op. Maar net zoals met Windows; je hebt het grotendeels zelf in de hand

[lf2]

"Dit heb je niet als je zelf dingen maakt"

Dat is echt een achterhaalde denk fout. Juist projecten zoals wordpress worden vaak het snelst gepatched. Doordat zo veel mensen ermee bezig zijn.

Alsof jij al jouw gemaakte websites bijhoudt op elke oude en nieuwe security flaw.

Daarnaast is WP handig om snel sites op te zetten.

[sygys]

Daarnaast heeft niet iedereen de resources en tijd om zijn of haar bedrijfswebsite zelf te bouwen. Ik zit momenteel op versie 4.2

Als je regelmatig bij wijzigingen een volledige backup maakt dan kunnen hackers doen wat ze willen. Je logged opnieuw in op je provider zet je website weer terug en het is weer opgelost.

Ik zal niet zeggen dat wordpress de ideale site is voor webwinkels of andere sites met privacy gevaar e.d. maar onze website met wat fotos van wat we maken en een contact formuliertje zijn prima voor wordpress. Daar ga ik zelf geen CMS voor schrijven.

[mxcreep]

Waar hij wel gelijk in heeft is dat bijvoorbeeld Wordpress snel herkent wordt en dat er wegens de grote hoeveelheid installaties veel tijd gestoken wordt in het hacken ervan. Als er eenmaal weer een hack beschikbaar is zie je meteen weer enorme hoeveelheden scans terug in je logfiles waar geprobeert wordt zo'n hack te exploiten.

Paar jaar geleden was Joomla het grote target, nu lijkt dat Wordpress te zijn geworden.

Zelf bouwen echter is uberhaupt wel een hele berg werk voor je iets functioneel vergelijkbaars hebt en ook dat onderhouden is enorm veel werk. Dan kun je beter nog voor een ander cms kiezen of meer een cms framework achtige oplossing.

Wat wel irritant is is dat elke gek sites maakt met Wordpress maar ze vervolgens niet update, met alle gevolgen van dien.

[Reactie gewijzigd door mxcreep op 22 juli 2024 15:14]

[Anoniem: 525224]

Indeed.

Niet veel programmeurs houden rekening met Owasp, waarin dit soort valkuilen staan.

Echter.. XSS.. is dat daadwerkelijk gevaarlijk, of is mijn definitie van een XSS exploit niet up to date?

Ik kende het als een methode om bijv. via een linkje zelf HTML te plaatsen op een website, waar je verder -nooit- last van hebt, behalve als ze die link gaan delen.

"Hij ontdekte dat WordPress een cross site scripting-kwetsbaarheid bevat, waarmee aanvallers eigen html- en javascript-code kunnen toevoegen aan een website. In dit geval zou een aanvaller daarmee een site kunnen overnemen."
- Volgens mij kan je hiermee nooit de site -zelf- kunnen overnemen, maar net doen alsof. De niet oplettende gebruiker kan erin trappen, maar overname is nooit ter sprake.

Sites overnemen doe je op een andere manier, dan front-end dingetjes faken. (sql injections, standaard administrator wachtwoorden etcetera)

Ik kwam er zelf mee in aanrekening (niet mijn systeem), omdat iemand een shortlink stuurde, die dan doorverwees naar een normale website met extra url parameters.. Waardoor er natuurlijk een kinderlijk plaatje kwam te staan met een doodskop en een beetje stoer-doenderij.

[dwilmer]

Ik kreeg gisteren zelfs een mailtje van mijn website dat-ie zichzelf had geüpdatet naar 4.1.2. Dat heb ik mijn eigen CMS'en nog niet zien doen.
[Edit: vlak nadat ik dit post komt er een mail binnen over de update naar 4.1.3.]
Toegegeven, die zijn ook niet gevoelig voor de bots die overal proberen aan te vallen, maar zodra iemand ze bewust probeert aan te vallen zijn ze denk ik een stuk sneller de sjaak.

[Reactie gewijzigd door dwilmer op 22 juli 2024 15:14]

[innerchild]

Niet iedereen is in staat om zelf een website laat staan een cms te ontwikkelen. Wordpress is nu eenmaal laagdrempelig opgezet juist voor mensen die dit niet kunnen of willen.

Ik koop een auto omdat ik dat makkelijker vind dan er 1 zelf te bouwen...

[janw.oostendorp]

Niet iedereen kan dat, en niet iedereen moet dat willen kunnen. En veel succes zelf maken wat er standaard in WordPress kan.

Gewoon zelf updaten en dan is de kan klein dat je iets overkomt.

[BuzzeW]

Als je de woorden tijd en geld samen gooit dan weet je al waarom. Als ik naar een klant stap en ik leg de klant uit dat ik hen een website kan aanleveren met Wordpress en met een eigen CMS systeem. Het Wordpress systeem is echter 25% goedkoper dan eentje met m'n eigen CMS. Wat denk je dat ze gaan kiezen? Inderdaad. Als jij een offerte maakt met je eigen CMS voor 5000€, dan is er sowieso een andere partij die het voor de helft doet met een Wordpress systeem. Voor de klant is dit hetzelfde.

[CH4OS]

Je moet dan echter nog wel zien te achterhalen welke versie van WP wordt gebruikt; een up-to-date versie is immers minder gauw vatbaar voor bugs waar oudere WP versies wel vatbaar voor zijn.

[fritek373]

Worden die exploit code's eigenlijk gepubliceerd door de "vinder" of Wordpress?

[CH4OS]

Zover ik weet niet, is bij eerderen ook nooit gedaan. Zie ook gerelateerde content. Ook heeft het weinig zin om dat te doen, het lek is in de nieuwste versie immers gepatched, het is dus een kwestie van tijd, voor een boel blogs over zijn naar deze versie. Waardoor de aanvaller dus zijn ruiten in gegooid heeft.

Daarnaast is 4.1.2 al even uit (hoe lang precies geen idee), waarover de Meuktracker van Tweakers gisteren al berichtte: downloads: WordPress 4.1.2.

[Reactie gewijzigd door CH4OS op 22 juli 2024 15:14]

[innerchild]

Gelukkig worden de meeste Wordpress sites automagisch geupdate sinds een tijdje. Scheelt een boel ellende. Zouden de makers van Wordpress trouwens kunnen zien hoeveel websites er draaien op oudere versies ? Ik neem aan dat Wordpress iets van een calling home functionaliteit heeft ingebakken aangezien oa mijn wordpress zichzelf automagisch update ?

[RobbyTown]

https://wordpress.org/about/stats/ kijk is aan

[innerchild]

Thanks. Compleet overheen gekeken

[Ewald !]

Uit de release notes van deze update:

We appreciated the responsible disclosure of these issues directly to our security team. For more information, see the release notes or consult the list of changes.

Edit: blijkbaar heb ik de vraag verkeerd gelezen

[Reactie gewijzigd door Ewald ! op 22 juli 2024 15:14]

[lordfragger]

In principe kan iemand met wat ervaring in het schrijven van exploits die vulnerability vrij snel vinden door de kwetsbare versie met de gepatchte te vergelijken.

Wordpress is grotendeels php code, dus die kan je gewoon lezen. Het aantal wijzigingen in zo'n fix versie is niet zo immens dat het onbegonnen werk wordt om de juiste change eruit te halen en te reverse engineeren.

[FrankSpin]

WordPress is een geweldig laagdrempelig platform. Iedereen kan binnen een paar minuten een website opzetten met WordPress. Diverse vaak gratis plugins en thema's zorgen voor extra gewenste functionaliteiten. Gaaf! Dit zorgt ervoor dat nu ongeveer 30% van de websites op WordPress draait, echt indrukwekkend.

De keerzijde van de laagdrempeligheid en de immense populariteit, is de wildgroei van vaak slecht onderhouden WordPress website. Door onkunde of gemakzucht worden websites vaak niet tijdig voorzien van nieuwe versies van plugins en thema's.

Dit maakt WordPress voor hackers en kwaadwilligen een zeer interessant platform. Je schrijft een keer een script en je laat het zoeken naar kwetsbaarheden. Met één script bereik je potentieel 30% van het internet, reken uit je winst.

Het maakt niet uit welk systeem je gebruikt. Het is altijd van belang dat je het onderhoudt. Als dit nu WordPress, Drupal, Django of LocomotiveCMS, het maakt allemaal niet uit. Wanneer je niet tijdig update's uitvoert ga je nat. Over het algemeen zijn mensen die WordPress gebruiken wat minder technisch onderlegt. Dat is een probleem.

[Faeron]

De bugs komen niet voort uit het feit dat Wordpress veel gebruikt wordt, maar uit het feit dat de ontwikkelaars te weinig (totaal geen als je het mij vraagt) aandacht hebben voor nette code en beveiliging. Wordpress is een goed voorbeeld van spaghetti code. DAT is het probleem, niet het feit dat het veel gebruikt wordt.

Ik gebruik een CMS dat, ondanks dat er nieuwe versies uitkomen, qua beveiliging goed op orde is en dus geen update nodig heeft. De update is er puur voor de nieuwe features. Oude versies draaien prima en veilig door, zonder dat ik daar aandacht aan hoef te besteden. Dat is hoe Wordpress ook in elkaar zou moeten zitten. Elk ander verhaal is makkelijk en naief wegkijken van de harde waarheid.

[Der Rudi]

Ben wel benieuwd welk CMS je dan gebruikt.

[downcom]

een beetje programmeur zet zelf een cms in elkaar. Wordpress gebruikt zoveel code en plugins terwijl je nog geen 5% gebruikt.

Daarom Zorg dat je die 5% goed in elkaar hebt zitten (maak dus iets zelf) en de rest verkoop je gewoon los als extra service (wanneer daar vraag naar is).

Daarnaast wordpress is eigenlijk bedoeld als blog (en nog steeds) dat er door allerlei aanpassingen er een cms uit rollen is dan niet vreemd maar efficient is het allerminst.

Het probleem zit hem in het feit open source onder een gratis licentie = lagere aanbiedingsprijs voor de klant = meer kans op verkoop. Dus commercieel snap ik de keuze wordpress wel achter het onderhoud is dan vaak van belabberde kwaliteit omdat de klant daar dan niet voor wil betalen.

Uiteindelijk zit je qua veiligheid toch beter bij een gesloten systeem maar dat is mijn mening. Ik zeg dus niet dat het niet vatbaar is maar de kans dat er iets in sluipt of dat derden de code kunnen bekijken en dus opzoek kunnen naar lekken is een stuk kleiner dan wel nihil.

[Reactie gewijzigd door downcom op 22 juli 2024 15:14]

[janw.oostendorp]

Ik betwijvel of je in je eentje (of met een team in een bedrijf) echt wat beters in elkaar kunt zetten. Je maakt mij niet wijs dat je minder gaten zult hebben dan een systeem wat zoveel gebruikt en getest wordt. En dus ook zo actief gedicht wordt.

Voordeel van je eigen systeem is dat vrijwel niemand de moeite doet om een custom CMS te kraken als je makkelijk gaten in verouderde bekende pakketten kunt aanpakken.

En dan heb ik het nog niet over de gebruiksvriendelijkheid van het systeem. Ook waar WP al vele 100en man-uren in heeft zitten.

[downcom]

Wat je niet nodig hebt hoef je dan ook niet te maken. En wanneer er vraag naar is vanuit de markt / klant dan kun je het toch maken?

Natuurlijk zet je niet even in een paar maanden een wordpress 2.0 neer maar dat is natuurlijk ook niet het doel. Je wilt je klanten bedienen op een efficiënte manier zonder dat dit gigantisch veel tijd kost. Nu is het zo als je wat plugins gebruikt dat dit wel eens gevolgen kan hebben voor je template. Ook hier moet je als bedrijf weer uren in steken (terwijl ik van mening ben dat dit service is) en het jouw als bedrijf geld gaat kosten (op langer termijn)

Wordpress is begonnen als blogging systeem en daar zijn wat mensen mee aan de haal gegaan om het te gebruiken als CMS. Al met al staat er nu een draak van een CMS zoals hier boven ook al aangegeven is verre van ideaal door het aan elkaar blijven knopen van code.

Ik zeg niet dat mijn keuze de beste is maar ik denk dat wordpress op langer termijn geld kost. (mits je natuurlijk een gekke klant hebt die voor elk telefoontje dat hij pleegt wil betalen)

[janw.oostendorp]

Mijn vraag is als een kant en klaar systeem 90% doet van wat de klant wil. Waarom ga je dan zelf uren er instekken?

Als je dan zo bang bent voor de beveiliging (terecht), dan kun je beter de tijd steken in zelf de backend extra dichttimmeren.

[Tryshasla]

Wij hebben bij ons in het bedrijf jaren aan een custom CMS gewerkt en het werkte, was snel, flexibel, bugs en security issues werden binnen no-time gedicht. Maar das was wel continu iemand mee bezig op kantoor. Wat een uren daar in ging zitten niet normaal. En uiteindelijk wilde onze klanten het op een gegeven moment niet meer. En daar zit je dan met een prima functionerend CMS, dus wij zijn juist overgestapt op WordPress omdat onze klanten (en dat zijn geen kleintjes) dat wilden.

En ondanks dat ik het systeem vervloekt heb toen we net begonnen omwille van hoe de code in elkaar zit: ik zou inmiddels niet meer terug willen naar ons eigen systeem. Het scheelt ons zo'n bak tijd om altijd maar bezig te zijn met het patchen van onze reeds opgeleverde sites. Bij WordPress klik je op een knop en bam de issues zijn gefixed.

Daarnaast is juist door die vervloekte code het systeem zo flexibel. Overal kan je wel in haken om iets te veranderen. Een admin interface is met custom post types zo opgezet en door wat dropins in elkaar te knutselen is zelfs WordPress snel te krijgen (of je gebruikt gewoon een bestaande caching plugin)

Maar boven alles: de klanten begrijpen hoe ze dingen kunnen aanpassen. Het is voor de eindgebruiker zo'n gebruikersvriendelijk product (zo lang je geen bestaande themes gebruikt met duizende useless opties die je site alleen maar traag maken); en uiteindelijk draait het daar om. Je wilt de klant tevreden houden en momenteel zijn ze dat met WordPress. Prima wat mij betreft.

[noopie]

+1

Mij lijkt October CMS een mooi alternatief.

[EpicEraser]

Ik vind Drupal persoonlijk een erg goed PHP CMS.
Het is netjes opgebouwd, en de spaghetti van Wordpress zul je er niet tegenkomen.

Nadeel is dat het een beetje lastiger is om plugins en skins ervoor te maken.
Het hele systeem is net ietsje minder flexibel dan Wordpress.
Daarnaast is de controle op plugins (review proces) op de website erg streng.
Aan de ene kant kost het veel moeite om zo'n plugin te publiceren, maar aan de andere kant kun je als gebruiker wel van enige kwaliteit uitgaan.

Althans, dit was mijn ervaring van ~twee jaar geleden, toen ik aan een plugin voor Wordpress, Drupal en Joomla (niet gebruiken, nog een grotere rotzooi dan Wordpress) aan het werken was.

[noopie]

Drupal vond ik erg gebruiksonvriendelijk, aantal jaar terug. Misschien dat het inmiddels beter is, in ieder geval bedankt voor de tip.

Dat is nog steeds wel zo (Wordpress), maar als je de gangbare goede plugins kent dan heb je (naar mijn idee) een goed, veilig en stabiel geheel.

Het gezeik begint vaak wanneer er off-the-shelf templates gebruikt worden (genoeg zelfvernoemde webbureautjes zonder goede technische kennis die dit gebruiken), met de nodige ingebakken luxueuze grafisch gelikte meuk (revolution slider anyone?) en andere copy paste ingebakken 'mogelijkheden'.
De klant zelf z'n hele site laten wijzigen, inclusief kleurenpalet, logo's.

Zit daar een lek in, is er geen hond die het kan updaten, want, spaghettisoep.

Maar een 'schone' Wordpress install, met 'schone' theme, geen rare plugins én een hostingprovider die bepaalde maatregelen weet te treffen, wp-admin htpasswd bijvoorbeeld = volgens mij safe. Natuurlijk ook netjes de updates installeren!

[Anoniem: 457607]

Volledig mee eens. De verantwoordelijkheid wordt wel erg makkelijk doorgeschoven naar de gebruikers van Wordpress.

Wanneer je software schrijft die miljoenen mensen gaan installeren dan is het een enorme design fout om te denken dat goed security beheer wel goedkomt op basis van de kunde en discipline van die gebruikers.

Dat gaat niet werken, heeft nooit gewerkt. Wordpress moet secure by default zijn, bij design. Dus laten we gewoon het beestje bij de naam noemen: het is ontiegelijke pruts software wat heel snel populair is geworden.

[StefanTs]

Beveiliging is in orde en heeft dus geen update nodig? Die gedachte alleen al is een enorm beveiligingslek.

[StefanTs]

Absence of evidence isn't evidence of absence...

Op hoeveel locaties draait dat ding van je? Zijn dit partijen die uberhaupt te maken zouden krijgen met hackers of zal het zomaar zo zijn dat niemand uberhaupt de moeite neemt om te kijken naar lekken? Enig idee hoeveel lek spul er nooit gehackt is omdat niemand er simpelweg interesse in heeft?

En ook al is je product zo enorm veilig, dat verandert m'n vorige opmerking nog niet. De arrogantie om te denken dat je product geen lekken bevat is gewoon een lek op zichzelf.

[Faeron]

Op hoeveel locaties draait dat ding van je?
- Op genoeg plekken.

Zijn dit partijen die uberhaupt te maken zouden krijgen met hackers...
- Oh, zeker!

M'n framework is geaudit door een Nederlands security bedrijf en die hebben niks gevonden. Een vorige versie van een bekende Nederlandse website op het gebied van ICT beveiliging draaide zelfs vele jaren op dat framework. En ja, die website kreeg elke dag te maken met vele hackpogingen. Geen een was succesvol.

Nu jij weer.

[StefanTs]

Sorry hoor, maar je noemt niets concreets en komt dan met "nu jij weer"? Zo kan ik ook een discussie voeren.

Als het zo'n groot, veelgebruikt systeem is dat zo geweldig is en door een eveneens onbenoemde partij is geaudit dan mag je toch echt wel iets concreter zijn.

Nu jij maar niet weer, want je discusseert toch niet op een normaal niveau.

[VincentdeVreede]

Ik kan alleen maar zeggen dat het mooi is dat er weer een kritieke bug gedicht is, maar hoeveel zitten er niet nog in Wordpress? En hoeveel mensen zullen hun Wordpress niet update waardoor het probleem zal blijven bestaan?

[sIRwa3]

Elke keer wanneer ik lees dat er weer een kritiek lek is gedicht in welk stuk software,kernel, noem maar op, voelt alsof ik van huis ben gegaan en s'avonds terug kom en er achter komt dat ik de voordeur wagenwijd open heb laten staan. (misschien is achterdeur een beter eufemisme)

veiligheid en software is werkelijk een illussie!

sorry voor erg offtopic zijnde

[Stranger__NL]

...en wordpress 4.2 is uit....

[Loekie]

Just one of many.
Het hele framework rammelt zo erg dat hosters het alleen nog in geïsoleerde containers willen draaien. Dat maakt het opruimwerk achteraf wat makkelijker.

[bobaas]

En jouw custom build cms is beter? Juist omdat het zo populair is blijf je gaten vinden. Automatisch updates aanzetten en je bent al een heel eind op weg.

[CMD-Snake]

Automatisch updates aanzetten en je bent al een heel eind op weg.

Daar zit het probleem, maar heel weinig mensen updaten hun Wordpress. Wat Java plugins zijn geworden voor het bezorgen virussen op een PC, dat is Wordpress geworden voor de verspreiding via lekken of kwaardaardige plugins waardoor de website ineens malware gaat serveren.

[b2vjfvj75gjx7]

Alle WP-versies achter de komma zijn security-patches en die worden (standaard) automatisch geupdate.

Je kan dit als webmaster overrulen door handmatig in de wp-config.php een andere variabele in te stellen - maar JanMetDePet zal dit niet doen / weten en is dus per definitie voorzien van security-patches.

Daarnaast is Wordpress eenvoudig in gebruik, maar wil dat niet zeggen dat je er geen omkijken naar hebt - je moet dus, net als elke andere site / CMS - de boel gewoon regelmatig aanpassen / updaten / etc...

Gebruik een cryptische username en cryptische (x 100) password, scherm je wp-admin af door een 301-redirect, schakel remote-access uit en wp-login.php voorzie je standaard natuurlijk van een .htaccess / .htpasswd firewall.

Verberg ook in de headers je WP-version en gebruik alleen legitieme plugins, ook al lijkt die nulled-plugin echt serieus helemaal gratis gegarandeerd veilig...

Daarnaast kan je WordFence installeren, die gratis 1x per dag een volledige scan doet van al je assets en repositories en trekt direct aan de bel als er iets verdachts aan de hand is (en daarnaast het aantal inlogs monitort, een extra layer van beveiliging aanbrengt en nog veel meer extra's biedt).

Als je dit als end-user niet wil, moet je geen Wordpress gebruiken en zelfs geen eigen site beheren - laat het dan gewoon aan de pro's over...

Een website bouwen en beheren is iets waar soms wat extra's bij komt kijken - als ik auto ga rijden zonder gordel ben ik ook dom bezig, en dat ligt niet aan de auto...

PS. Ik heb jaren met een eigen / custom-build CMS gewerkt - los van het feit dat ik meer tijd kwijt was om dat ding te bouwen / onderhouden / patchen dan dat ik daadwerkelijk met de sites zelf bezig was, bleek het ook nog onveilig.

Ik heb een keer een audit laten doen door een security-bedrijf en die hadden een x-aantal serieuze leks ontdekt waar ik zelf (en vele anderen met mij - ik had +/- 50 actieve (zakelijke) gebruikers, soms met meer dan 200.000 unieke gebruikers per maand) nooit achter was gekomen... Je waant je veilig met je eigen code, maar is dat ook echt zo?

Pas sinds ik WP gebruik verdien ik eindelijk geld aan een CMS, in plaats van dat het me uren (en dus geld) kost...

Ander voordeel - voor de klant - is dat er geen vendor lock-in is; ik kan mijn sites gewoon overdragen aan een ander en anderen dragen ze over aan mij. Intern kan een bedrijf altijd wel iemand vrijmaken die met WP aan de slag kan voor content-updates en dat hoef je met een eigen CMS niet te verwachten;

Ze hebben geen mankracht / kennis om dat te leren en als ze van je af willen (of het aan een ander overdagen) dan snapt die A] vaak niets van jouw "unieke" CMS en B] vaak wil je de codes niet eens overdragen; voor je het weet gaat een ander er dan mee aan de haal...

[Reactie gewijzigd door b2vjfvj75gjx7 op 22 juli 2024 15:14]

[Verwijderd]

En toch zijn er hosters die Suphp niet ondersteunen of nog werken met maprechten, waardoor deze feature gewoonweg vervalt en je afhankelijk bent van handmatig updaten met het invoeren van FTP gegevens of het overschrijven van bestanden door middel van FTP.

[b2vjfvj75gjx7]

Dat is dan een kwestie van een provider zoeken die het wel ondersteund...

Of simpel weg handmatig via de terminal de apache-config aanpassen, zodat je de FTP-user gelijk trekt aan die van de "WP-user" (al denk ik dat ze dat al helemaal niet toelaten...).

[Tjolk]

Mja, is dat een excuus?
Als je als websitebeheerder geen geld wil uittrekken voor fatsoenlijk gereedschap, dan kun je ook niet verwachten dat alles vlekkeloos verloopt.

Als in: koop een auto goedkoop bij een particulier met garantie totdat de deur dichtgaat, of ga toch liever naar een BOVAG garage met standaard 3 maanden garantie.

[Loekie]

Ik heb geen custom build, wij gebruiken dit ding ook. Maar pas sinds gebruik van containers hebben we er veel minder werk van. Ook een volledig up2date WP trekt nog steeds schorriemorrie aan die met 0day soms alsnog binnenkomen, met containers kunnen we gewoon discarden, en nieuwe clean rollout en verder.

[Faeron]

Dit is echt een slap en onzinnig excuus en daar moeten we mee stoppen. De gaten worden niet alleen gevonden omdat Wordpress veel gebruikt wordt. Ze worden ook gevonden omdat ze erin zitten!

En ja, mijn custom build CMS is beter.

[Stranger__NL]

Volgens mij zeg je dat verkeerd:
"..., mijn custom build CMS is beter."

Volgens mij bedoel je een van de volgende:

Jouw custom CMS kan niets, dus is het niet te hacken
Jouw custom CMS draait op een stand-alone webserver die geen connecties met het internet heeft dus het is niet te hacken
Jouw custom CMS draait op een custom OS die niet te hacken valt want niemand kent het
Jouw custom CMS heeft veel minder functionaliteit dus is het misschien minder makkelijk te hacken.
Jouw custom CMS heeft zo weinig users (0) dat het niet te hacken is omdat het nergens gebruikt wordt.

...

Geef eens details over jouw custom CMS....
Dan vertel ik jou waar het gat zit.

[Faeron]

Oke: http://www.banshee-php.org/ En als je niks vindt, wees dan zo sportief om dat dan te zeggen.

[s.stok]

OK bij dezen,

[code]
if ($user["password"] === hash(PASSWORD_HASH, $password.hash(PASSWORD_HASH, $username))) {
[/code]

Remote timing attack, zo onveilbaar is het nu en je maakt niet eens gebruik van salting en iteration of wat dan ook.

Je project kan best goed zijn, maar superieur of onfeilbaar zoals je nu voor doet komen is compleet onzin.

Citaat van hierboven:
[quote]
De bugs komen niet voort uit het feit dat Wordpress veel gebruikt wordt, maar uit het feit dat de ontwikkelaars te weinig (totaal geen als je het mij vraagt) aandacht hebben voor nette code en beveiliging. Wordpress is een goed voorbeeld van spaghetti code. DAT is het probleem, niet het feit dat het veel gebruikt wordt.

Ik gebruik een CMS dat, ondanks dat er nieuwe versies uitkomen, qua beveiliging goed op orde is en dus geen update nodig heeft. De update is er puur voor de nieuwe features. Oude versies draaien prima en veilig door, zonder dat ik daar aandacht aan hoef te besteden. Dat is hoe Wordpress ook in elkaar zou moeten zitten. Elk ander verhaal is makkelijk en naief wegkijken van de harde waarheid.
[quote]

"Wordpress is een goed voorbeeld van spaghetti code."
Toegegeven het kan inderdaad stukken beter.

Maar! Jouw project is ook één al spaghetti code.
Je zegt (oprecht) dat Wordpress één al spaghetti code is en volgens draag je je eigen project aan wat niet eens veel beter is van architectuur.

* Je doet overal en nergens aan file logging (dus geen mogelijkheid dit vervangen met een centrale logger). Daarnaast is file logging blocking is en dus vertragend!
* global scope variables zijn een recept voor problemen, je executie gebeurd overal en is totaal niet te voorspellen. Dit breekt met wel zoveel principes van goede structuur.
* Inconsistente strikte "===" vergelijking van booleans, soms wel soms niet
* [code]/* Pages in database
*/
$conditions = $rids = array();
foreach ($this->record["role_ids"] as $rid) {
array_push($conditions, "a.role_id=%d");
array_push($rids, $rid);
}[/code]

Wat is er nu sneller dan 40 OR statements uitvoeren in ipv van IN() statement.
En "!=" niet standaard SQL dat is "<>". Daarnaast is array_push langzamer dan gewoon $conditions[] te gebruiken.

Als je project echt geweldig was zoals een modern en vooral veilig CMS of eCommerce project (met al dan niet een eigen framework als basis) had je echt recht van spreken maar dit is onzin.

Je begint allereerst met Wordpress af te kraken, geeft dan JOUW EIGEN SYSTEEM als alternatief (wat niet eens veel beter is op de punten die jij benoemd) en word vervolgens geïrriteerd omdat mensen je niet series nemen. Doe je zelf en andere een lol en hou het gewoon netjes (je commentaar en code), en niet eindeloos rond bazuinen dat jouw project geweldig is tot andere.

Als jouw project echt zo geweldig is dan hoef je er niet eens over te praten, dat doen andere wel voor je. - Bescheidenheid siert de mens.

Edit. En toen bleken code blokken niet te werken in reacties

[Reactie gewijzigd door s.stok op 22 juli 2024 15:14]

[Faeron]

Er wordt WEL gebruik gemaakt van salting, maar blijkbaar kan jij niet zo goed code lezen.

Je remote-timing attack is niet waar, dus die mag je even toelichten.

Je mag mijn code spaghetti code vinden, maar er zit een duidelijke structuur in en netjes volgens MVC. Je bewering is niet meer dan een niet onderbouwde goedkope flame, die negeer ik dus maar.

Overal en nergens aan file logging? Waar heb je het over? Ook graag toelichten.

Global scope variables zijn volgens jou een recept voor problemen, maar niet in Banshee. Het gaat namelijk slechts om een paar globale configuratie variabelen. Hoor graag je concrete bewijs waarom dat volgens jou wel een security issue is. Desondanks ben ik zelf ook niet zo'n liefhebber van globals, dus in de komende versie zijn die er al uitgehaald.

Over je push_array en in() opmerking: leuk geprobeerd, maar zo lang Banshee nog steeds sneller is dan Wordpress, lijkt me dat niet zo'n issue.

Het wel of niet gebruiken van "===" is niet inconsistent, maar bewust wel of niet gedaan. Leer eerst eens goed PHP voordat je dit soort onzin commentaar geeft. En wijs anders maar aan waar het fout gaat.

Leuke poging tot het leveren van kritiek, maar je punten zijn nogal magertjes, niet onderbouwd en behoorlijk subjectief. Als je qua kritiek niet met iets beters kan komen dan dit, dan heb ik met Banshee dus iets goeds neergezet. Dank voor je bevestiging.

[Reactie gewijzigd door Faeron op 22 juli 2024 15:14]

[s.stok]

Er wordt WEL gebruik gemaakt van salting, maar blijkbaar kan jij niet zo goed code lezen.

Ik kan prima code lezen, maar gezien het totale gebrek aan structuur en kwaliteit kan je niet verwachten dat dit met één opslag duidelijk is. OK, je gebruikt iets dat lijkt op salting https://github.com/hsleis...8/libraries/user.php#L139

Een gebruikersnaam, nee dat is lekker random zeg.
Toegegeven PostgreSQL gebruikt dit ook maar als die template0 word gehackt heb je wel een groter probleem

Daarnaast gebruik je dan nog steeds geen gebruik van iteration.
http://security.stackexch...-when-using-pkbdf2-sha256
https://www.owasp.org/ind...e_Cheat_Sheet#Work_Factor
https://www.owasp.org/ind..._credential-specific_salt

Je remote-timing attack is niet waar, dus die mag je even toelichten.

Nee doe je maar toelichten (nee ik DAAG JE UIT) waarom dit zogenaamd niet waar is je gebruikt wel is waar een hash om te vergelijking dus hebben deze een constante lengte maar een remote timming attack gaat veel verder dan dat, intern word bij het vergelijking gestopt op het eerste verschil. http://blog.ircmaxell.com/2014/11/its-all-about-time.html

Zelf een theoretische aanval is genoeg reden om dit serieus te nemen, als je echt zoveel om beveiliging geeft als je zegt, denk je hier niet zo licht over.

Je mag mijn code spaghetti code vinden, maar er zit een duidelijke structuur in en netjes volgens MVC. Je bewering is niet meer dan een niet onderbouwde goedkope flame, die negeer ik dus maar.

https://github.com/hsleis...ibraries/user.php#L32-L42 lekkere MVC structuur, je HTTP laag (Controller) is compleet verweven met het security systeem. MVC is meer dan een View map, Ik zag in een ander bericht dat je op ZendFramework 2.0 zat af te geven omdat er zogenaamd geen MVC structuur is. Guess what, MVC Is een design pattern geen mappen structuur... MVC gaat over het scheiden van gedrag en presentatie, het is een ideaal (een denkwijze), als je dit al een flame vindt.

Voor de duidelijkheid.
http://framework.zend.com...dules/zend.mvc.intro.html

Overal en nergens aan file logging? Waar heb je het over? Ook graag toelichten.

https://github.com/hsleis...ibraries/banshee.php#L174
https://github.com/hsleis...8/libraries/user.php#L349
https://github.com/hsleis...tabase_connection.php#L48

Geen centraal systeem voor loggen, dus niet te vervangen met een andere oplossing.
Mede omdat de class final is (alleen een opmerking geen flame. dit just een goed iets ).

https://github.com/hsleis...8/libraries/error.php#L93
Heerlijk, wie wil er nu niet begroet worden met 500 mails omdat je er één foutje in de code zit.
Alleen in een nood situatie zoals een fatale database fout zou ik een mail willen ontvangen.

Global scope variables zijn volgens jou een recept voor problemen, maar niet in Banshee. Het gaat namelijk slechts om een paar globale configuratie variabelen. Hoor graag je concrete bewijs waarom dat volgens jou wel een security issue is. Desondanks ben ik zelf ook niet zo'n liefhebber van globals, dus in de komende versie zijn die er al uitgehaald.

Niet in Banshee nee, maar Banshee is (aldus de website) een Framework! Je kan niet voorspellen hoe mensen jouw code gaan gebruiken één global variabel die door iemand verkeerd word gebruikt kan het hele systeem kapot maken. Of dat je zelf een nieuwe global variabel introduceert (die al door iemand word gebruikt in zijn eigen code), je code is niet langer te voorspellen. Met een goed gestructureerde class kan je precies bepalen wat er gebeurd, iedere class resulteert in een uniek object. Dat object doet (mits goed geprogrammeerd) één ding en niks meer, globals werken ook buiten de class zelf door. Waarom denk je dat PHPUnit de mogelijkheid heeft om ze terug te kunnen zetten? Omdat ze voor onverwacht gedrag zorgen!

Je hebt de kracht van classen en objecten, dus waarom zou je vandaag de dag nog globals gebruiken? Dit had je allang op kunnen lossen (ik ken dit project al langer dan gisteren).

Een global vervangen voor een injected service (perfect), maar gebruik dan wel iets van interfaces of class type hinting. https://github.com/hsleis...98/libraries/user.php#L25 je kan niet nog steeds niet volledig vertrouwen op het ontvangen van het juiste object.

Over je push_array en in() opmerking: leuk geprobeerd, maar zo lang Banshee nog steeds sneller is dan Wordpress, lijkt me dat niet zo'n issue.

Klein of niet het is een issue (en makkelijk op te lossen dus waarom zou je tijd verdoen met dit verdedigen. Daarnaast heb ik een keer in phpBB meegemaakt dat de query de mist in ging door te veel OR cases), daarnaast is Wordpress wel wat uitgebreider dan dit systeem.
Zo is een statische HTML sneller dan een dynamische website.

Wil je perse een CMS project hebben dat wel kwalitatief in elkaar is gezet?
https://github.com/pagekit/pagekit

- Gebouwd op moderne beproefde standaarden.
- Unit tested
- Modulair dus makkelijk uit te breiden en aan te passen.
- Gestandaardiseerde logging oplossing (PSR-3)

Vergelijk DIT is met Banshee of Wordpress

Het wel of niet gebruiken van "===" is niet inconsistent, maar bewust wel of niet gedaan. Leer eerst eens goed PHP voordat je dit soort onzin commentaar geeft. En wijs anders maar aan waar het fout gaat.

0 == 'foo' is true (BOEM!), het advies is om altijd een stricte vergelijking te gebruiken omdat je zo problemen voorkomt voordat ze gebeuren. Voorkomt overigens ook problemen zoals dit: http://www.pfz.nl/forum/t...se-of-undefined-constant/

De hoofdregel voor leesbare en voorspelbare code is consistentie en eenzijdigheid. Had overigens nog niet gehad over je styling, soms staat return op een eigen regel en soms niet, zeur ik? misschien maar één van de renen waarom andere voor Ruby of Python is kiezen is dat leesbaarheid al onderdeel is van de taal zelf, in Python kan je niet alles op één regel kwakken en hopen dat het werkt, PHP, C en vele andere hebben dit niet en juist daarom moeten we erop letten dit zelf toe te passen! Of je nu 2 spaties gebruikt voor een tab of 4 spaties, of dat je { altijd op zijn eigen regel plaats of alleen scope blokken zoals functies/classen, doe het consistent. En dat is iets waar Wordpress het toch echt beter doet dan jij

Leuke poging tot het leveren van kritiek, maar je punten zijn nogal magertjes, niet onderbouwd en behoorlijk subjectief. Als je qua kritiek niet met iets beters kan komen dan dit, dan heb ik met Banshee dus iets goeds neergezet. Dank voor je bevestiging.

"Als je qua kritiek niet met iets beters kan komen dan dit", hoor wie het zegt je promoot alleen maar je eigen project omdat Wordpress niks is en vergelijkt dan ook nog is een complete CMS oplossing met een simpel statisch structuur systeem.

"Dank voor je bevestiging."
Ik bevestig helemaal niks , dat is jouw idee, kennelijk ben je al net zo goed in lezen dat je bent in overzichtelijk programmeren

Was ik nog vergeten te melden.
- Geen unit tests, hoewel gezien de structuur van dit systeem dat vrijwel onmogelijk is.
Geen tests nodig? Ga je alles met de hand testen, dat zelfs de simpelste wijziging een uur werk vereist om er zeker van te zijn dat er geen neven effecten zijn. Gezien de structuur is dat een immens risico.
- Geen documentatie, "To understand how Banshee works, just start reading public/index.php and everything will be clear. Promise." Nee dat is uitgebreide documentatie zeg, hoe maak ik een nieuwe module? hoe werk ik met het gebruikerssysteem, hoe maak ik formulieren? Nee ik ga geen berg code lezen. Ik wil NU direct kunnen zien of wat zodat ik een afgewogen beslissing kan nemen of dit geschikt is voor mijn volgende project. Zo is hoe iemand die op jouw website komt denkt.

Ja, de meeste frameworks hebben een berg documentatie, gelukkig maar! Symfony is een vreselijk goed voorbeeld hoe het moet. Leesbaar, vriendelijk, beknopt tot hoofdzaak (heb je meer informatie nodig? dan is die er ook maar apart zodat je niet overdonderd raakt met allerlei details).
Ik heb liever documentatie voor iets dat ik hoogstens één keer moet doen, dan dat moet ik gaan uitzoeken hoe dit vredesnaam op te lossen en het dan vervolgens nog verkeerd doet (met alle veiligheidsproblemen vandoen).

[Reactie gewijzigd door s.stok op 22 juli 2024 15:14]

[Faeron]

Salting:
Misschien moet je je nog even verdiepen in het hoe en waarom van salting. Voor iedere gebruiker een unieke salt is beter dan een vaste.

Iterations:
Weet ik, iets voor in de toekomst. Maar daarbij, je moet wel eerst een dump van de database te pakken krijgen voordat dit iets van betekenis heeft. En daar wens ik je veel succes bij.

Remote-timing:
Ik weet wat een remote timing attack is. Maar deze is dusdanig theoretisch en met de rest van de verwerking dusdaning onbetrouwbaar, ik wens je ook hier veel succes mee.

Spaghetti:
De controller is mijn HTTP laag? Snap je wel hoe HTTP en MVC werkt? Je klinkt alsof je ergens een klok hebt horen luiden.

Logging:
Wow, overdrijven is een kunst, maar jij bezit die gave tot in den puntjes. Omdat ik een andere aanpak (niet slechter of beter) dan jij zou kiezen is dat een minpunt van het framework? Je excuus van 'willen vervangen door een andere oplossing' is behoorlijk vaag en slap. En over die 500 mails: dan ben je de volgende keer tenminste wel scherp en leer je het af om fouten te maken of niet goed te testen. Ik ontvang iig nooit een e-mail van al mijn op-Banshee-gebaseerde websites. Je bent dus weer lekker aan het overdrijven.

Global:
Het ging oorspronkelijk over veiligheid en je zakt nu wel erg af om een punt van kritiek te vinden. Maar fair enough, ik had het al aangepast voor de komende versie. En los van of het er al inzit of niet, ik kan niet voorkomen dat mensen die mijn framework gebruiken zelf globals gaan gebruiken.

Push_array():
Zelfde als hierboven: het ging over veiligheid, niet over tot in de puntjes uitpersen van performance.

Pagekit:
Ken ik niet, zal best prima zijn, ga ik niet in detail bekijken. Eerste indruk is dat het iig er beter uitziet qua opzet dan Wordpress.

Documentatie:
Hoezo geen documentatie? http://www.banshee-php.org/documentation

===:
Nogmaals, wijs maar aan waar het fout gaat in Banshee. En wat betreft leesbaarheid: Banshee is prima leesbaar. En als je Wordpress, dat HTML code, controller-code, SQL queries en zelfs Javascript-prints door elkaar heeft staan, beter gestructureerde code vindt, dan neem ik je echt niet meer serieus en zijn we uitgepraat (zijn we geloof ik al).

Je hebt met al je kritiek geen concrete zwakheid in Banshee aangetoont. Al je opmerkingen zijn over minime performance dingetjes, theoretische aanvallen en subjectieve zaken over de opzet. Ik heb nooit gezegd dat Banshee perfect is. Als het niet aansluit bij jouw smaak / voorkeuren, gebruik het vooral niet. Maar over Banshee is 1000x meer nagedacht over de structuur en beveiliging dan Wordpress. Mijn feitelijke opmerking is dan ook: gebruik iets anders dan Wordpress. Maakt niet uit wat, maar na de zoveelste security bug is het het stom om Wordpress te blijven gebruiken en is het je eigen domme schuld als je daarmee gehackt wordt.

[Reactie gewijzigd door Faeron op 22 juli 2024 15:14]

[s.stok]

Misschien moet je je nog even verdiepen in het hoe en waarom van salting. Voor iedere gebruiker een unieke salt is beter dan een vaste.

Waar zie jij in vredesnaam dat ik het heb over een vaste salt? Ik weet ik ook wel dat dit random moet zijn per gebruiker en het liefst cryptografisch random (dus niet simpel mt_rand()) .

Weet ik, iets voor in de toekomst. Maar daarbij, je moet wel eerst een dump van de database te pakken krijgen voordat dit iets van betekenis heeft. En daar wens ik je veel succes bij.

Juist voor dit soort situaties moet je voorbereid zijn, een security expert zou dit toch moeten weten je hoeft maar één lek te hebben (back-up in publieke map of USB stik gestolen met dump) dit werkt verder door dan alleen de website zelf.

Wow, overdrijven is een kunst, maar jij bezit die gave tot in den puntjes. Omdat ik een andere aanpak (niet slechter of beter) dan jij zou kiezen is dat een minpunt van het framework? Je excuus van 'willen vervangen door een andere oplossing' is behoorlijk vaag en slap. En over die 500 mails: dan ben je de volgende keer tenminste wel scherp en leer je het af om fouten te maken of niet goed te testen. Ik ontvang iig nooit een e-mail van al mijn op-Banshee-gebaseerde websites. Je bent dus weer lekker aan het overdrijven.

Ik overdrijf niet, ik zeg alleen wat ik observeer. Ja kan ik struikelen over één spatie teveel of te weinig, maar ik focus liever op alle details dan alleen wat belangrijk is

En over die 500 mails: dan ben je de volgende keer tenminste wel scherp en leer je het af om fouten te maken of niet goed te testen.

Ja, maar dan moet testen wel mogelijk zijn hé! juist vanwege de huidige opbouw is geautomatiseerd unit testen vrijwel onmogelijk.

Je excuus van 'willen vervangen door een andere oplossing' is behoorlijk vaag en slap.

Want je rijd immers nog steeds in de zelfde auto, loopt elke dag in de zelfde kleren als je huis te klein word doe je maar spullen weg? Als je bezoekers aantal groeit wil je daarop kunnen anticiperen, alleen vast zitten een file-based logging oplossing gaat dan echt een probleem worden. Een goed systeem houd daar al rekening mee, en bied de mogelijkheid om dit te vervangen voor iets dat beter werkt. Waarom denk je dat ze anders DI hebben uitgevonden? Juist, om iets kunnen vervangen als dat nodig is.

De controller is mijn HTTP laag? Snap je wel hoe HTTP en MVC werkt? Je klinkt alsof je ergens een klok hebt horen luiden.

Mijn originele bericht "je HTTP laag (Controller) is compleet verweven met het security systeem." De controller is verantwoordelijk voor de communicatie tussen Models en Views. Dat is de basis, maar de controller is niet simpel één class of iets het is een "principe", dus je controller werkt voor de UI communicatie (form invoer (HTTP), Request afhandeling (HTTP), Action handler voor knop in een desktop applicatie (Qt/GTK of iets)) en gebruikt op zijn beurt weer allerhande services om dit uit te voeren.

HTTP laag in dit verhaal is een laag die zorgt voor communicatie, een systeem dat een Request verwerkt en een Resonse (View) teruggeeft. MVC is niet 1-op-1 toepasbaar op HTTP vanwege het state-less ontwerp van HTTP.

In jouw huidige opzet werkt de User class direct met de HTTP laag (dus vervult de taak van een Controller), maar doet ook gebruikers ophalen uit de database en weer opslaan.
In een gescheiden opzet heb je een Controller laag die de Request (waaronder HTTP POST) verwerkt dit op een transparante manier communiceert naar een User systeem welke het daadwerkelijke inlog proces voltooit (communicatie terug naar de HTTP laag om een cookie/sessie te zetten). Het User systeem communiceert (met hulp van andere services) met de controller laag en doet niets zelf met HTTP.

Mijn definitie van spaghetti code is dat er geen duidelijk punt is van invoer of uitvoer, en dat een class meerdere taken vervult. Direct loggen naar een bestand (zonder enige vorm van abstractie), gebruik van globals (omdat de uitvoer niet langer te voorspellen is) en ook (hier komt tié) doorwerkt op andere onderdelen, er is geen duidelijke scheiding van lagen en structuur ("alles" doet maar iets; loggen, HTTP informatie verwerken, gebruikers invoer valideren (nee ik heb het niet over afdwingen van juiste informatie) net voor het in de database gaat terwijl het al veel eerder moest worden gecontroleerd), copy paste database queries.

Ik ben wel is waar gewend aan moderne oplossing zoals Symfony, Silex, Zend Framework en CakePHP maar zelfs in Symfony 1.4 werden al geen globals meer gebruikt.

Als het niet aansluit bij jouw smaak / voorkeuren, gebruik het vooral niet.

Je zou zij zelf "En als je niks vindt, wees dan zo sportief om dat dan te zeggen."

Ik zeg toch wat ik er van vindt, misschien niet heel mild of iets maar dat is mijn mening hoe ik er over denk, ik zeg niet dat compleet slecht is (je die indruk krijg je alleen). Ik geef punten aan die naar mijn een mening een probleem zijn.

Om af te sluiten, de grootste kans op een veiligheidsrisico is onduidelijke code zonder scheiding van structuur, en gebrek aan bruikbare unit tests om toekomstige werking van het systeem te waarborgen. Veiligheid is meer dan alleen beschermen tegen SQL injections en XSS, het is ook het waarborgen van de continuïteit van juiste werking.

Banshee is misschien veilig omdat het nog nooit is gehackt en geen lekken zijn gevonden (of zelfs aanwezig zijn) maar dat doet niks af aan het feit dat de structuur een beter kan.
Ik ben juist blij dat het veilig is, maar kan ik problemen in de opbouw gewoon niet negeren, dat is hoe ik erover denk, dat is wie ik ben en daar kan ik niks aan veranderen.

[Reactie gewijzigd door s.stok op 22 juli 2024 15:14]

[Faeron]

Je verhaal is wederom behoorlijk subjectief en benoemt geen concrete kwetsbaarheden in Banshee. Dus nogmaals bedankt voor de bevestiging.

En Symfony? Serieus... DAT is pas spaghetti code (ja, ook dit is subjectief).

[Stranger__NL]

Open en eerlijk - Dat verdient een eerlijke reactie terug.

Ik ben geen security-auditor, maar heb wel even gekeken. Ik vind het altijd leuk/interessant om te zien wat anderen bouwen. Je CMS bevat een basis waarmee je een website in de lucht kunt krijgen, maar het is in geen manier te vergelijken met de functionaliteit die ik vereis aan een cms-ervaring die Wordpress, Drupal, Sitefinity, Sharepoint of Joomla standaard met zich meebrengt. (ja ik weet het - groot verschil in prijs/functionaliteit etc)...

Zonder je CMS aan te willen vallen, maar om toch een concreet voorbeeld te geven:

- Een simpel inschedulen van publicatie en depublicatie van een nieuwsbericht zul je nog moeten bouwen. Dat is eenvoudig te maken, maar mijn beoogde klant-doelgroep wil dit gewoon _NU_ hebben, en niet X dagen wachten tot het ontworpen, gebouwd, getest en gereleased is.

- Geïntegreerde media-library met drag-and-drop mappen is een basis functie waar ik niet zonder kan. Die moet je nog maken; doe je dat zonder (bijv) het trage niet-secure jQuery en zonder bekende grafische php-libraries/plugins dan is jouw ontwikkeltijd ineens weken, zoniet maanden. Dat voelt misschien wel veilig, maar je moet dan wel echt _heel_ goed programmeren wil je in je eigen code niet een 'ongelukje' veroorzaken. Achterdeurtjes zijn zo (per ongeluk) gemaakt.

- Paginatemplates ontbreken. Geavanceerde kolom-indelingen die een standaard gebruiker van een communicatieafdeling niet stuk maakt door een keer teveel op backspace te drukken. Als je dit hebt gemaakt is jouw CMS weer honderden/duizenden regels code groter. Code waarin mogelijk ergens een gaatje is ingeslopen. De audit die je op die honderden regels moet uitvoeren kost weer tijd en geld om het weer heel secure te maken.

... kortom ... Het komt een beetje neer op wat ik in mijn eerdere bericht zeg: "Jouw custom CMS heeft veel minder functionaliteit dus is het misschien minder makkelijk te hacken. ".


The good part:
Je gebruikt in je framework bijna geen externe includes, standaard geen WYSIWYG editor en zover ik zo zag geen jQuery of andere bekende libraries(met hun bekende bugs) waardoor ik snel kan opzoeken of er bekende lekken bestaan.

Je heartbleed is up-to-date.
Je poorten staan netjes open en dicht waar dit nodig is.

So far _mijn_ kennis van hacken en controles.

Maar:
- Je hebt geen brute-force controle op inloggen. Met een dictionary-script heb ik het admin (die username bestaat) pwd meestal binnen een uurtje of 8
- je hebt geen secure password policy (ik mag een user aanmaken die root/root heet)
- je gebruikt een PHP webserver: https://web.nvd.nist.gov/...4&search_type=all&cves=on
- Je gebruikt MySql : https://web.nvd.nist.gov/...l&search_type=all&cves=on
- je hebt de CKeditor: https://web.nvd.nist.gov/...r&search_type=all&cves=on
- <alu hoedje> en dan heb ik nog niks gezegd over de ingebouwde mogelijkheden door de NSA</alu-hoedje>

...en toen was mijn korte test voorbij en ik hoop dat ik mijn punt gemaakt heb dat een eigen CMS geen garantie is voor een lek-vrije omgeving. Zelfs niet bij een minimale functionaliteit.

Je bent _wel_ minder snel doelwit van algemene hackbots/scriptkiddies, maar net zo snel gehacked als je specifiek getarget zou worden.
En dan de uitsmijter: stel je voor DAT je getarget zou worden... en ze komen stilletjes binnen en wijzigen iets kleins... kom je dat dan automatisch te weten? Is er intrusion detection/filechangedetection,.... of zou iemand maanden in het geheim kunnen meekijken zonder dat je het door hebt?

In jouw verdediging: Alle bovenstaande problemen gelden ook voor _alle_ CMS systemen. Zeker ook Wordpress. Maar je opmerking "mijn custom CMS is beter" is misplaatste grootspraak. Geen absolute waarheid.


/Respect

[Faeron]

Een simpel inschedulen van publicatie...
Geïntegreerde media-library met drag-and-drop mappen...
Paginatemplates ontbreken...
- Het ging om de veiligheid. Ja, het is minder gebruiksvriendelijk dan Wordpress, maar zelf heb ik niet meer nodig. Mocht ik ooit voor een website iets meer moeten bouwen, dan doe ik het dan wel en voeg het toe in het framework.

Je hebt geen brute-force controle op inloggen. Met een dictionary-script heb ik het admin (die username bestaat) pwd meestal binnen een uurtje of 8
- Nope, via actieve monitoring heb ik dat snel genoeg door. En als ik wil blokkeer ik dat via mijn webserver (https://www.hiawatha-webserver.org/)

je hebt geen secure password policy (ik mag een user aanmaken die root/root heet)
- Nou en? Dat is security by obscurity. En wachtwoorden worden (in de gebruikersprofiel pagina) wel degelijk gecontroleerd op lengte en complexiteit.

Je gebruikt een PHP webserver.
- Een wat? Nee dus. Zie eerste antwoord.

Je gebruikt MySql.
- Wat heeft dat met mijn framework te maken? Daar ging het feitelijk om.

Je hebt de CKeditor.
- Dus? Daar mag je niks mee. Bestanden uploaden naar webserver kan niet.

<alu hoedje> en dan heb ik nog niks gezegd over de ingebouwde mogelijkheden door de NSA</alu-hoedje>
- Damn, ik ben erbij!

Als ik getarget zou worden, dan merk ik dat ook. Zie https://www.hiawatha-webserver.org/monitor

Wat mijn punt is: als die Wordpress gasten hun interface op mijn framework zouden bouwen, wat voor een mooi product zou je dan hebben...

[Reactie gewijzigd door Faeron op 22 juli 2024 15:14]

[Stranger__NL]

Je hebt me. Jouw oplossing is feilloos en onhackbaar.

[Soldaatje]

Ja bugs zitten er in, net zoals in elke soft/hardware.
Belangrijker is dat ze op tijd gefikst worden.

[Faeron]

Tuurlijk is geen enkel stuk software foutvrij, maar Wordpress is het meest extreme voorbeeld. Waarop bewust kiezen voor het meest brakken en onveilige CMS dat er bestaat?!? Dan doe je het jezelf ook gewoon aan!

[Soldaatje]

Volgens mij overdrijf je dat lichtelijk.

[Armin]

WordPress heeft een fundamenteel probleem dat het framework write access naar zichzelf vereist. Dat is ivm updates. Dat is een ontwerpfout die die zorgen dat klwetsbaarheden in zichzelf of enige plugin vrij makkelijk een infectie van de site kan veroorzaken.

Als men de plugins en standaard framework content management code write access zou kunnen ontnemen, is het grootste probleem weg. Echter dit schijnt moeilijk te zijn omdat het fundamenteel in de code zit.

[[Yellow]]

Dat is simpelweg niet waar. Het is niet fundamenteel noodzakelijk.
Het maakt het makkelijk, ja.
Maar als je WP in productie omgevingen inzet zul je ervoor zorgen dat het geen schrijfrechten naar zichzelf heeft (behalve op de upload folder).
Eenmalig een scriptje schrijven dat een upgrade doet, je gegevens migreert en de folder en file permissies goed zet en je bent in 1 minuut naar de nieuwe versie over.

[Armin]

Het is niet fundamenteel noodzakelijk.
Het maakt het makkelijk, ja.

Het staat default aan.

Het kan inderdaad in principe uit, maar die functionaliteit is niet (makkelijk) beschikbaar. Je ziet diverse organisaties daarom WordPress in sandboxes draaien. Maar je moet dus moeite doen, en dat gebeurt meestal niet ...

[erwinwernars]

misschien niet beter, maar wel uniek

[batjes]

Wat is er mis met PHP? 1 van de weinig zo uitgebreide (script)talen die puur bedoelt is(was) voor het web. Tevens erg goed te gebruiken als bat/batch scripts.

[Patriot]

Wat is er mis met PHP? 1 van de weinig zo uitgebreide (script)talen die puur bedoelt is(was) voor het web. Tevens erg goed te gebruiken als bat/batch scripts.

Met PHP an sich kan ik gelukkig wel leven, ik gebruik het zelf ook. Het is wel een taal die vaak op hele foute manieren gebruikt wordt. Meer dan andere talen, althans zo is mijn ervaring. Dat gebeurt bij Wordpress ook, je hebt bijvoorbeeld plugins die je blog ombouwen tot webshop, dat slaat toch nergens meer op?

[aadje93]

waarom niet? Wordpress is makkelijk, gebruiksvriendelijk en een webshop intergreren in je site is dan erg makkelijk. Het thema valt gelijk mooi samen met je huis thema, de wat minder gevorderde gebruiker kan dan zo een webshop maken voor zijn blog (bijvoorbeeld planten/tuin benodigheden als je over tuinieren blogt) Dat is totaal niet vreemd. En waarom is PHP een slechte keuze? Het is 1 van de weinige talen die juist voor het web bedoeld is. Waar wilde je het anders voor gebruiken, om een 3D game te maken?

[innerchild]

Rakend aan jouw onderwerp die je hier aansnijd zou ik gebruikers wel streng adviseren om je webshop zoals een woocommerce in een eigen wordpress omgeving te laten draaien.

Mocht je website in de problemen komen door bv het verwijderen van data in je database of nog erger door fouten gemaakt door het installeren van plugins dan draait je webshop nog steeds en vica versa.

Hoe ik dit zelf doe is als volgt :

- Installeer de website in www.website.nl
- Installeer de webshop in webshop.website.nl ( Als een sub domein )

Vervolgens ontwerp ik zowel de website als de webshop in dezelfde huisstijl en link ik de webshop in mijn website zodat het voor de gebruiker als 1 geheel word ervaren.

Zo verspreid ik het risico en vermijd je het probleem dat alles compleet plat gaat. En natuurlijk niet vergeten je website te backuppen en NOG belangrijker om deze een keer te testen. Een leuke makkelijke manier om dit te doen voor de huis tuin en keuken gebruiker is de website : www.myrepono.com. Krijg je nog 5 dollar gratis ook waarmee je je website voor zeker 2 jaar gratis kan laten backuppen en het terug zetten is een kwestie van een druk op de knop geven en wat koffie gaan drinken.

[aadje93]

sub domein is zowieso logisch, maar alsnog omslachtig omdat je dan richting duplicate content gaat (seo...) dit is weer te onder vangen met rel=canonical maar het vereist veel werk. Gewoon voor elke update etc. even een backupje maken op de server, en dagelijks een off-site backup en je zit al goed volgens mij.

[innerchild]

Duplicate content ??? De ene wordpress instance draait de website en de andere draait een webshop en die link ik vanuit de website. Enigste wat ik doe met de webshop is het aanpassen van de kleuren/fonts/lettertypes.

Nog nooit last van gehad met seo..

[Patriot]

Rakend aan jouw onderwerp die je hier aansnijd zou ik gebruikers wel streng adviseren om je webshop zoals een woocommerce in een eigen wordpress omgeving te laten draaien.

Dat is natuurlijk helemaal te gaar voor woorden. Als je een plugin niet denkt te kunnen vertrouwen je data intact te laten, waarom gebruik je hem dan

[innerchild]

Omdat ik een paar keer door het testen van diverse plugins mijn database naar de filistijnen heb geholpen. En je komt er pas achter als het te laat is. Bv laatst zocht ik naar een lightbox plugin en na het testen van 10+ plugins deed mijn website ineens funky. Kon bepaalde menu opties niet meer openen en op sommige pagina's kreeg ik errors te zien. Met mijn beperkte kennis van mysql en php liep ik dus vast.

Gelukkig test ik wel alles eerst op een test platform dus zo speel ik safe.

Buiten dat is dat stukje waar je op reageert een veilige manier imo om kritische onderdelen van een website van elkaar te scheiden. Er zijn meer wegen die naar Rome leiden en deze methode die ik gebruik vind ik prima werken.

[Patriot]

waarom niet? Wordpress is makkelijk, gebruiksvriendelijk en een webshop intergreren in je site is dan erg makkelijk. Het thema valt gelijk mooi samen met je huis thema, de wat minder gevorderde gebruiker kan dan zo een webshop maken voor zijn blog (bijvoorbeeld planten/tuin benodigheden als je over tuinieren blogt) Dat is totaal niet vreemd.

Ik redeneer uiteraard niet vanuit het oogpunt van de eindgebruiker die uiteindelijk geen regel code ziet. Het gaat mij om de programmeur die ervoor kiest om dergelijke brokken functionaliteit in een plugin te stoppen terwijl die gewoon een plaats verdienen in een eigen applicatie.

Het gaat me ook meer om mensen die vanaf het begin ontwikkelen vanuit Wordpress voor wat voor website ze dan ook maken. Daar had ik wel duidelijker in mogen zijn.

En waarom is PHP een slechte keuze? Het is 1 van de weinige talen die juist voor het web bedoeld is. Waar wilde je het anders voor gebruiken, om een 3D game te maken?

PHP is geen slechte keuze voor het maken van blogsoftware of een webshop, dat heb ik ook niet gezegd

[pizzafried]

Wat is in jou ogen een foute manier? plugins die een blog ombouwen tot webshop is niet per definitie een foute manier van gebruik van een programmeertaal.

[Patriot]

Wat is in jou ogen een foute manier? plugins die een blog ombouwen tot webshop is niet per definitie een foute manier van gebruik van een programmeertaal.

Het op deze manier gebruiken van plugins is in mijn ogen verkeerd. Je gaat de scope van datgene wat je aan het uitbreiden bent zo ver voorbij dat je niet meer van een plugin kunt spreken.

Wordpress is in beginsel nog teveel gewoon blogsoftware. Het probeert zich wel te positioneren als CMS/framework, maar daarin schiet het tekort als je kijkt naar de beschikbare alternatieven.

[batjes]

PHP heeft gemiddeld veel meer bobo's die er in "programeren" in vergelijking met PERL, Python, ASP.NET e.d.

Zou zelf ook geen Wordpress gebruiken, aantal keer het plezier gehad er mee te mogen werken