Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 83 reacties
Submitter: redburn

WordPress heeft een week voordat versie 3.9 uitkomt een kritiek lek in zijn contentmanagementsysteem gedicht, waarmee kwaadwillenden zich toegang via nagemaakte authenticatie-cookies konden verschaffen. Ook zijn drie kleinere lekken gedicht.

Het lek zit niet alleen in versie 3.8, die door de patch naar versie 3.8.2 wordt gebracht, maar ook in versie 3.7 en de vroege versie van 3.9. Ook voor die versies heeft WordPress updates uitgebracht. De patch die het lek moet dichten heeft de aanduiding CVE-2014-0166 gekregen. De kwetsbaarheid werd door WordPress zelf ontdekt.

Naast dit kritieke lek zijn er drie minder urgente patches uitgebracht en negen bugs geplet. Zo helpt een patch hosts om mogelijk kwaadaardige requests bij het verwerken van pingbacks te verwerken, is een mogelijkheid om sql-injecties uit te voeren verholpen en is de mogelijkheid om cross-domain scripting via de Plupload-bibliotheek uit te voeren ongedaan gemaakt. WordPress is automatische bijgewerkt voor diegenen die dit zo ingesteld heeft; overigen zullen het cms zelf moeten bijwerken.

Moderatie-faq Wijzig weergave

Reacties (83)

Wat ik doe is dit:

Allereerst installeer ik WP-CLI: http://wp-cli.org

Vervolgens maak ik /root/updatewpcli aan met deze inhoud:
#!/bin/bash
LD_LIBRARY_PATH=/opt/intel/lib/intel64
export LD_LIBRARY_PATH
cd /usr/share/wp-cli/
/usr/bin/php composer.phar self-update
/usr/bin/php composer.phar require 'wp-cli/wp-cli=@stable'
Dit draai ik vervolgens in de hoofd crontab met
@daily /root/updatewpcli
Vervolgens maak ik /home/hans/wordpresssite/www/backup.sh aan met deze inhoud:
#!/bin/bash
#Use the updated PATH environment variable
LD_LIBRARY_PATH=/opt/intel/lib/intel64
export LD_LIBRARY_PATH
export PATH=/usr/share/wp-cli/bin:$PATH
#Go to the document root folder for your web server, for example /var/www/
cd /home/hans/wordpresssite/www/
#Optimize the database tables
wp db optimize
#Export the database in a sql dump file which name consists of the database name and the day of the export
wp db export /var/backups/wp/"`grep DB_NAME wp-config.php | awk -F "'" '{print $4}'`_`date +%y-%m-%d`.sql"
En maak ik /home/hans/wordpresssite/www/update.sh aan met deze inhoud:
#!/bin/bash
#Use the updated PATH environment variable
LD_LIBRARY_PATH=/opt/intel/lib/intel64
export LD_LIBRARY_PATH
export PATH=/usr/share/wp-cli/bin:$PATH
#Go to the document root folder for your web server, for example /var/www/
cd /home/hans/wordpresssite/www/
#Update the core WP installation
wp core update
#Update all plugins
wp plugin update --all
#Update all the themes
wp theme update --all
Daarna zet ik dit in de crontab van de desbetreffende web-user:
0 1 * * * /home/hans/wordpresssite/www/backup.sh
30 2 * * * /home/hans/wordpresssite/www/update.sh
Op die manier wordt de database iedere nacht gebackupped, geoptimaliseerd, alle plugins en thema's bijgewerkt en natuurlijk de Wordpress-core zelf.
Succes! :)

[Reactie gewijzigd door Hans van Eijsden op 9 april 2014 12:13]

Klinkt heel goed, maar doe jij nooit aanpassingen aan plugins? Want dan overschrijf je in de meeste gevallen automatisch je aanpassingen. Simpel voorbeeld is contact form 7, als je daar de css van wijzigt, en je update hem, dan worden je css aanpassingen overschreven.
De meeste plugins bieden override van CSS-instellingen via hun eigen config, wat ze opslaan in de database. Wanneer dit niet het geval is, maak ik een child-theme aan waarin ik de wijzigingen doorvoer. Op https://codex.wordpress.org/Child_Themes kun je zien hoe dat moet.

Wat je anders ook kunt doen is dit, zoals ik net las op de site van WP-CLI:
--skip-plugins global flag
Ever used WP-CLI to install a plugin that broke WP-CLI? Well, now there’s a 100% sure way to deactivate it: wp --skip-plugins plugin deactivate naughty-plugin.

You can also skip only particular plugins: wp --skip-plugins=admin-blocker,complex-beast.

[Reactie gewijzigd door Hans van Eijsden op 9 april 2014 13:03]

True. ik heb bijvoorbeeld iDeal betalingen in WooCommerce moet proppen.
Kan ik nu niet zomaar updaten. Moet ik altijd handmatig doen :(
waarmee kwaadwillenden zich toegang via nagemaakte authenticatie-cookies konden verschaffen.
Lol... Ben laatste dagen zelf bezig geweest met usersystem te maken voor een projectje van mij, maar ik had hier zelf wel aangedacht zodat mensen niet via cookies zomaar toegang kunnen krijgen op andere accounts... (terwijl eerste keer is dat ik via cookies werk ipv alleen sessions :P) Schaam u WordPress!

Zelf kan ik trouwens ook niet updaten:

Download mislukt.: Operation timed out after 299846 milliseconds with 3174016 out of 6791465 bytes received
Ik heb de patch even wat grondiger bekeken dan alleen vooroordelen te geven op basis van een vage omschrijving.

Wat hier gebeurt is typisch PHP. Het is via de externe plugin interface mogelijk om een authenticatie hash mee te geven. Dit hoeft niet per se een hash te zijn, maar kan ook gewoon een string, of in geval van de hack, een int te zijn. Waar het mis gaat is de type-tolerantie van PHP en automatische conversie die daarbij hoort.

if ($expected_hash == $hash) {
//pass
}

Laat $expected_hash nou bijvoorbeeld 6ee4169e310cbe59b47e2ec50630fa77 zijn en $hash 6. Wat PHP dan doet is de md5 hash naar int converteren, wat 6 oplevert, en omdat de vergelijking niet strict wordt gedaan levert dat true op en ben je binnen. Welke hashing mechanisme je gebruikt doet er niet toe, zodra een hash met een cijfer begint is het hackbaar.

De fix die toegepast is, is de inputwaarden nog eens hashen en dan strict type checken.

Meer info:
http://joncave.co.uk/

Fix:
https://core.trac.wordpre...8054&sfp_email=&sfph_mail=
Je eigen security bouwen is meestal gebaseerd op security through obscurity. Je kan beter een populair open-source systeem pakken wat door experts is geschreven en bekeken, en waar talloze hackers hebben geprobeerd om in te breken. Zie http://security.stackexch...-shouldnt-we-roll-our-own

[Reactie gewijzigd door Blaise op 9 april 2014 09:29]

Als ik op jouw link klik lees ik meer over de algoritme die gebruikt wordt, echter maak ik niet mijn eigen algoritme maar gebruik ik sha384/512 (met unieke salt voor elke user, weet het niet de beste methode maar iig beter dan MD5 of SHA1) waar < PHP 5.5 op staat en bcrypt waar PHP 5.5 (of toekomstige versies) op staat.

Of mis ik nu iets en bedoel je wat anders? :)
Niet enkel het algoritme is belangrijk, maar de implementatie ook.
Veiligheidslekken zijn vaak geen fouten in het algoritme maar in de implementatie. Zo kan een programma mathematisch perfect in orde zijn maar wel vatbaar zijn voor een timing attack.
Bekijk zeker ook eens de nieuwe functies om een paswoord te hashen in php 5.5.0 "password_hash" (http://www.php.net/manual/en/function.password-hash.php). Deze gebruikt automatisch de allerlaatste (hopelijk ook veiligste) manier om een passwoord te hashen. Verder kun je bij iedere login kijken of het wachtwoord opnieuw gehashed moet worden om zo de beveiliging te verbeteren wanneer het algoritme geupdate word "password_needs_rehash" (http://www.php.net/manual...password-needs-rehash.php).
Als het hashing algoritme wijzigt per PHP versie is het niet heel handig om automatisch de "default" te gebruiken, aangezien wanneer deze verandert je password checks het niet meer gaan doen :P
Toch wel, password_verify kijkt zelf hoe het paswoord in je database gehashed in en gebruikt de deze hashing techniek ( op dat moment misschien niet de laatste) om het wachtwoord te vergelijken. Daarna doe je best password_needs_rehash om te controleren of er een nieuwe hash nodig is die WEL de laatste versie gebruikt. Is dit niet zo dan hash je het door de gebruiker net ingevoerde wachtwoord met de nieuwe hashfunctie door gewoon opnieuw password_ash op te roepen ;)! Het zou zwak zijn moesten ze daar niet aan gedacht hebben.

function authenticate ($username,$password)
{
//Laad gebruiker uit database
$user = ... (ophalen uit database aan de hand van gebruikersnaam)

if (password_verify($password, $user->getPassword())) {
//Gebruiker is nu ingelogd
...
if (password_needs_rehash($user->getPassword(), [hashtype] , [hashopties bv cost])) {

$newpassword = password_hash($password, [hashtype] , [hashopties bv cost]);
//Nieuw wachtwoord opslaan in database
...
}
}
}
Vandaar dat je ook de password_verify functie (http://www.php.net/manual/en/function.password-verify.php) hebt.
Precies. Zoals OpenSSL. Na twee jaar komt er vanzelf een update.
Hoewel je technisch natuurlijk gelijk hebt met `security through obscurity` heb je daar alleen mee te maken met een gerichte aanval op je site. Bij veel van de standaard CMS'en krijg je geautomatiseerde attacks op basis van de bekende zwakheden.

Maar als je niet (goed) weet wat je doet moet je het zeker niet zelf gaan doen en is een standaard CMS zeker veiliger.
Mensen, stop toch eens met Wordpress. Hoe lang moet het duren voordat je doorhebt dat het een onveilig product is? En gezien de spaghetticode waar het uit bestaat zal het waarschijnlijk ook nooit veilig worden.
Ieder CMS heeft wel lekken. Als je de website waar je naar linkt er op na slaat heeft ieder bekend honderden vulnerabilities:
- WordPress: 954
- Joomla: 593
- Drupal: 728
- TYPO3: 183

Afgaande van mijn korte lijstje, waar ongetwijfeld een paar grote namen in missen, zouden we dus allemaal voor TYPO3 moeten gaan. Jammer alleen dat dat een erg lastig CMS is. Ik heb er mee gewerkt en het is een mooi en krachtig systeem maar met een enorme leercurve.

Het mooie van WordPress is dat je relatief eenvoudig een simpele website op kan zetten. Voor iemand die niet veel meer dan dat wil is het een prachtig platform. Ik ben wel met je eens dat het v.w.b. de code een enorme spaghetti is.

Daarnaast bevatten de aantallen hierboven ook alle vulnerabilities in plugins. Als je de betreffende plugin niet gebruikt, heb je dat lek dus ook niet.

Daarnaast gaat het er mij ook om hoe snel een lek gedicht wordt.

Sowieso ben je met alles wat aan het internet verbonden is altijd kwetsbaar, welk systeem/OS/CMS je ook gebruikt. Daar veranderd geen enkel systeem iets aan en het enige devies is bijhouden en patchen waar nodig is.

[Reactie gewijzigd door RvL op 9 april 2014 09:17]

Of geen CMS, voor zover de use case dat toestaat.

Als je een web-developer bent, kun je voor je eigen projecten ws. prima toe met een simpel framework of een static site generator.
Als je web-developer bent wel, maar de gemiddelde gebruiker is geen web-developer ;)

En vaak wordt er een website voor iemand gebouwd. Die persoon zal de website dan ook vaak zelf gaan vullen en bij gaan houden. Dan is een CMS wat redelijk WYSIWYG is een stuk eenvoudiger dan steeds een static site aan moeten passen.
Om pagina's te kunnen aanmaken, bewerken en verwijderen en op te maken met een wysiwyg-editor heb je geen WordPress-achtig systeem nodig. Dat kan prima met een simpel (maatwerk) systeempje.

90% van de features van een platform als WordPress zal de doorsnee gebruiker nooit gebruiken, terwijl het systeem vanwege de populariteit en regelmatige ontdekking van bugs wel veel onderhoud nodig heeft.
Dat ben ik met je eens.

Echter, maatwerk is niet per definitie veiliger. Natuurlijk, de user base is kleiner dus zal het minder snel de interesse van kwaadwillenden trekken; zij raken immers liever een grote groep gebruikers dan 1 gebruiker.

Nadeel van maatwerk vind ik dat er vaak geen of nauwelijks updates voor komen. Het systeem werkt zodra opgeleverd en zal best stil blijven staan maar tenzij er echt grote bugs of kwetsbaarheden inzitten, zal het niet snel bijgewerkt worden. Daarnaast is, juist vanwege de kleinere user base, de kans dat een kwetsbaarheid gevonden wordt een stuk kleiner.

Ik wil hiermee niet impliceren dat een groot CMS altijd beter is dan een maatwerkpakket. Beide hebben hun voordelen en nadelen.
Veiligheid is uiteraard altijd in de handen van de de ontwikkelaar die achter de knoppen zit.

Als je met een relatief eenvoudige (en veilige) oplossing precies kunt bieden wat een klant/organisatie nodig heeft, is er over het algemeen geen noodzaak voor updates. Tenzij de eigenaar zelf vraagt om nieuwe features, waarbij de bouwer een adviserende rol kan hebben.

Als de kans dat een kwetsbaarheid gevonden wordt (en op grote schaal uitgebuit) kleiner is, zou ik dat niet gelijk een nadeel noemen.
"Ieder CMS heeft wel lekken."

Oh ja? :+
Dat een lek nog niet gevonden is, wil niet zeggen dat het er niet in zit natuurlijk ;)

Natuurlijk spreekt het in hun voordeel dat ze zeggen dat het framework is geschreven met beveiliging als belangrijkste aspect, maar het is wel een beetje 'wij van WC Eend'. De melding dat een Nederlands bedrijf een vroege versie heeft geaudit is ook redelijk niets zeggend: er zijn nieuwe versies uitgekomen sindsdien en hoe uitvoerig was die audit?

Overigens wel even met de demo gespeeld. Ziet er op zich niet slecht uit, zeker voor een relatief eenvoudige website kan het best goed zijn..

[Reactie gewijzigd door RvL op 9 april 2014 09:41]

"De melding dat een Nederlands bedrijf een vroege versie heeft geaudit is ook redelijk niets zeggend"

Ben ik niet met je eens. Blijkbaar zit de auteur dus mijn zijn aanpak op de goede weg. Netzoals een security-bug-rijk verleden iets zegt over een product, zo zegt een security-bug-arm of zelfs security-bug-vrij verleden ook iets over een product.
Dat laatste ben ik zeker met je eens.

Ik doelde meer op het feit dat iedereen een dergelijk statement op z'n website kan zetten. Het internet staat vol met (on)waarheden.

Het feit dat de auteur ook de auteur van de Hiawatha webserver is zegt natuurlijk wel iets.
Banshee is een Framework volgens hun site.

Framework != CMS ;)

[Reactie gewijzigd door ThePope90 op 9 april 2014 09:36]

Framework met CMS, kijk zelf maar.
Klik op 'CMS' rechtsboven, inloggen met admin:banshee.

[Reactie gewijzigd door Faeron op 9 april 2014 09:41]

An earlier version of Banshee has been audited by a Dutch IT security company. No issues were found.
Welke firma is dat? Waarom laten ze geen rapport zien? Als ik het systeem bekijk, dan kan het de vergelijking met WP absoluut niet doorstaan.
Waar ik benieuwd naar ben is waar deze cijfers op gebaseerd zijn.
Ik vraag me af hoeveel die cijfers van een aantal lekken lekken, aangezien ze direct correleren met de populariteit van het desbetreffende CMS. Betekent gewoon dat er meer gevonden zijn, omdat er ook meer mensen naar op zoek zijn bij populairdere CMSen. Eigenlijk een beetje nietzeggende statistiek in deze context dus :P
Over het algemeen betekend dat het aantal lekken die bekend zijn. kan dus ook zijn dat bij wordpress meer bekend is als bij TYPO3 ;)
de honderden vulnerabilties bevat ook derde partij extensies..
verklaart de cijfers...
Anyway.. naast de cijfers moet je ook de "unpatched" score zetten..
Gekeken bij de oorsprong:
bij WP is er niet alles gepatched, zelfs niet by Typo3 en Drupal.. wel bij Joomla overigens..
Dus we moeten voor Joomla gaan dus..
Noem eens een net zo functioneel alternatief dat wel veilig is?
Het Banshee PHP framework. Ja, Wordpress is veel gebruiksvriendelijker. Maar misschien moeten we van het idee af dat elke idioot een website kan hosten. Een computer is een complex apparaat. Omdat softwarepakketten zoals Windows en Wordpress het voor Jan-en-alleman bruikbaar hebben gemaakt, neemt dat niet weg dat de computer een complex apparaat is.

Wil je een website hosten, zorg dan dat het door goede ICT-ers is opgezet. Dus Wordpress enkel en alleen als een ICT-club het technisch onderhoud op een goede manier doet. Dus niet zelf ergens Wordpress gaan lopen installeren. Wil je echt iets zelf doen, dan is dat Banshee framework een prima en veiliger alternatief. Het nadeel is dat het wat minder gelikt is qua interface. Maar ja, je moet ook niet voor een dubbeltje op de eerste rang willen zitten.
Net even proberen te installeren; hij gaat ervanuit dat ik een gebruiker root heb op mijn mysql server. Die heb ik uit veiligheidsoogpunt natuurlijk een andere username gegeven....
Ik denk dat elk alternatief dat populair wordt, automatisch kwetsbaar wordt.
Gewoon goed bijhouden, da's alles wat je kunt doen.

Ik ken nog steeds mensen met een mac die geen virusscanner hebben. Stak laatst een usb memory stick van zo'n pipo in mijn laptop en heb meteen 34 verschillende virussen voor hem opgeruimd... stond ie mooi te kijken.. waanzin.. maar dit geheel terzijde..
Je eerste zin is nogal een onzin-stelling. Ik daag je uit om een serieuze kwetsbaarheid in Banshee te vinden.
Volgens mij zijn het vooral de plugins van externen die je kan installeren in Wordpress die kwetsbaar zijn! Een schone Wordpress valt wel mee, en snelle updates!

[Reactie gewijzigd door heinoh op 9 april 2014 09:00]

Stop dan maar meteen goed en gooi je internet de deur uit :>
Haha, vaak zie je ook als er ergens een 'cyber' aanval is een stockphoto van Wordpress sourcecode als afbeelding :+
Wordpress lek, OpenSSL lek, 21.9% van de website's te pakken. Mooi moment om de server software, de SSL certificaten n de Wordpress installaties eens te vernieuwen. Ben je in een keer van het gedoe af.

[Reactie gewijzigd door unglaublich op 9 april 2014 08:51]

Yup, Wordpress installatie vernieuwen met grote kans dat al je plugins stoppen met werken en je maar moet hopen dat er een update voor is.
Vele plugins werken zelfs met 3.9 rc1
Dat is gewoon het risico van 3rd party plugins en wordpress. Wordpress levert geen ondersteuning voor oudere versies, dus je MOET altijd upgraden. Als je dan 3rd party plugins hebt die niet meer werken is dat pech. Alternatief is een lek systeem blijven draaien en uiteindelijk afgesloten worden door je hoster.
Precies! Dat is dus vaak het probleem met dit soort 'webapplicaties' bouwen :)
Nog erger, niet alleen een lekke Wordpress installatie maar stel je al die schrale 3rd party semi-closed source plugins eens voor met een gebrek aan fatsoenlijke security auditing. Wat moet dat een lek mandje zijn.
Correctie: 16,0%. Niet alle V3 versies van WordPress bevatten dit beveiligingslek.
Welke versies niet? Heb nog wat oudere V3-versies draaien en zie het niet zo zitten die te moeten udpaten. Of gewoon alle versies vr 3.7 niet?

[Reactie gewijzigd door Snooby op 9 april 2014 11:46]

Vraag me dit ook af, heb veel oudere versies draaien die custom plugins hebben die niet werken met de nieuwere versies.
Als ze niet vatbaar zijn voor dit lek, dan zijn ze wel vatbaar voor andere lekken... Hoe onmisbaar zijn die custom plugins, of hoe haalbaar is het om ze te patchen zodat ze wel op de nieuwste versie werken?
Als goede beheerder doe je dit natuurlijk regelmatig. Dit hoort mijns inziens bij een goede dienstverlening.
Ik probeer op dit moment om een Wordpress website deze update uit te laten voeren maar hij hangt als een baksteen in het download process !
Ik heb hetzelfde probleem.
En site is automatisch geupdate van 3.8.1 naar 3.8.2
een andere site automatisch geupdate van 3.7.1 naar 3.7.2 (bevat dezelfde securtiy patch)
een site die ik handmatig wil updaten geeft een 500 server error.
een andere site fie ik handmatig wil updaten begint 3.8.2 NL te downloaden maar blijft daarin hangen.

Is eigenlijk voor het eerst dat ik problemen ondervind met updaten, normaal volstaat n klik.
Ik denk dat het grootste deel Wordpress sites nu aan het updaten is, en de servers wel overbelast zullen zijn :)
Dat denk ik ook, kreeg net een mailtje:

Je site op http://example.nl naar WordPress 3.8.2 bijwerken.

We hebben het geprobeerd, maar we konden je site niet automatisch bijwerken. Bijwerken van WordPress is makkelijk en het duurt maar eventjes:
http://example.com.wp-admin/update-core.php

Je site up-to-date houden is belangrijk voor de veiligheid. Het maakt het internet daarmee ook een veiligere plek voor jou en je lezers.

Indien je problemen ervaart of hulp nodig hebt; de vrijwilligers van de WordPress.org support forums kunnen je waarschijnlijk helpen.
http://nl.forums.wordpress.org

Het WordPressteam
Maar alleen de Nederlandstalige de Engelse doet het hier wel.

(Download mislukt.: Operation timed out after 300001 milliseconds with 2345434 out of 6791465 bytes received)

[Reactie gewijzigd door iamfrankenstein op 9 april 2014 08:59]

Nou inderdaad. Beetje jammer dit.... Krijg hem met geen mogelijkheid nu geupdated.
Ik heb net geprobeerd om het handmatig te downloaden van nl.wordpress.org , het werkt wel maar het gaat enorm traag (minder dan 25 kB/sec) . Dit zal de reden wel zijn dat onze updaters falen , het binnenhalen duurt simpelweg veel te lang. Het bestand is 6,5 MB.
Oke. Bedankt voor de heads up!
Dank om dit op de front pagina te zetten :D Heb meteen mijn 3 Wordpress installaties die ik beheer van een update voorzien. ;)
als ik wordpress installeer doe ik dat normaal met installatron en laat die ook meteen alles automatsich updaten naar een nieuwe versie. Bij word[ress kun je dit beter meteen zo doen gezien de toch groot aantal problemen in het verleden. Handmatig updaten kan dan weer te lang duren, c.q. kost toch weer tijd.
Wel leuk dat automagisch updaten maar als je een x aantal plugins hebt draaien die vitaal zijn voor het functioneren van je website kan je zo op je gat vallen.

Dit werkt alleen als je bv elke dag een update maakt of nog beter, maar ik weet niet of dat in de functionaliteit van installatron is ingebouwd, is dat voordat er magisch word geupdate even een backup word gemaakt.
Kun je ook instellen dat je een backup maakt.
Daarnaast kun je ook in wordpress iedere dag naar een andere ftp server een backup laten maken. Ik gebruik updraftplug gratis plugin.
Tip: wp-sentinel.
Tip je nu een plugin die al meer dan 2 jaar niet is geupdate ? ;(
hoef niet probeer maar
Voor de systeembeheerder met veel vhosts (op linux werkt waarschijnlijk ook op BSD):

find / -type d -name 'wp-includes' -exec grep -H 'wp_version =' {}/version.php \;

Geeft mooi lijstje met versies. Zoekt uiteraard niet in tarball archieven e.d.
Maar wat dan wel?

Joomla, Drupal, Sitefinity, Sharepoint, ... vertel vertel.
Zelfgeschreven code zonder lekkages (HAHAHAHA, ... sorry)?
Of heb je een platte HTML-site? Waar draait die op dan?

in voorgaande reacties kun je zien dat ook dat (helemaal) niet de heilige graal is.
Je kunt best WP installeren, en als je dan je server ook een beetje beveiligd met intrusion detection, malwarescanner dan kun je jaren probleemloos draaien.

En if all else failes: dan hebben we de dagelijkse backup en zijn we binnen een uurtje weer up-and-running.
Dat je reactie een +2 score heeft toont alleen maar aan dat de meeste bezoekers weinig kaas hebben gegeten van security.

Deze opmerking gaat me zeker een -1 opleveren, maar soit.

Een security strategie is om geen software platformen te gebruiken die een slecht security track record hebben.

Voorkomen is beter dan genezen.

Een intrusion detection system, malware scanners, het is de klok horen luiden, maar niet weten waar de klepel hangt.

En die backup is al lang al naar de klote omdat je nooit door hebt gehad dat je al maanden gehacked was en de backup niet meer ok was.
CVE-2014-016, dat is toch de officile naam van de heartbleed bug? Heeft die hier iets mee te maken, of was dat gewoon een leuke naam? :?

EDIT: ah, slecht gecopy-pastet van mij dus :p

[Reactie gewijzigd door Goderic op 9 april 2014 09:49]

Van de website van Heartbleed:
Q&A
What is the CVE-2014-0160?

CVE-2014-0160 is the official reference to this bug. CVE (Common Vulnerabilities and Exposures) is the Standard for Information Security Vulnerability Names maintained by MITRE. Due to co-incident discovery a duplicate CVE, CVE-2014-0346, which was assigned to us, should not be used, since others independently went public with the CVE-2014-0160 identifier.
Er staat dus nog een nul achter :P
De heartbleed bug is CVE-2014-0160 en dit is CVE-2014-0166

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True