Veel partijen hebben inmiddels ook al verbeteringen doorgevoerd. Jammer dat daar eerst weer zo'n onderzoekje voor nodig is en dat zoiets niet meteen een hoge prioriteit heeft bij de partijen. Anno 2016 zou je toch denken dat cybersecurity bij iedere instantie hoog op de agenda staat.

Ruis....onrust....ware bedreiging wordt niet belicht....Welke ware bedreiging wordt niet belicht? Graag wat meer gedetailleerde uitleg!

De piraten partij doet het iets beter op bepaalde punten. Leuk om te zien.

Maar slechter dan D66, valt me dus eigenlijk erg tegen..

https://www.htbridge.com/ssl/?id=7a61ff6e6b24b473d2b4ec56777a9c9d806e8baa4a6cd326f11724a56c6e08a6
https://www.ssllabs.com/ssltest/analyze.html?d=piratenpartij.nl

Doet mij goed als beheerder van de Piratenpartij.nl websites :D

Wel jammer dat het niet gebruiken van Google Analytics geen bonus punten oplevert. Dat hadden groene vakjes moeten zijn.

TheYOSH

"Geen van de partijen heeft de beveiliging helemaal op orde" is nogal een domme uitspraak eigenlijk. Neem de maatregelen om alle vakjes uit die sheet op groen te krijgen, en je verliest een groot deel van de doelgroep. Bereikbaarheid is ook een groot goed voor een politieke partij.

Haha wat een knullig verhaal:

- HOOG RISICO!!1!: PVV had geen HTTPS. Website bevat alleen publieke info, geen aanmelding. Lekker belangrijk.
- Even een paar andere sites bekeken: ook publieke info en geen aanmeldingen. Dus andere HTTPS-instellingen: lekker belangrijk.
- Google analytics series probleem want kan code injects doen. Serieus? LOL! Vergeet de platformboeren dan ook niet te noemen (MS, Debian, ...) want die kunnen ook kwaadaardige code pushen m.b.v. updates.
- Slager vergeet eigen vlees te keuren:
- gebruik TLSv1.0 is EVIL. Een keer raden of sijmen.ruwhof.net TLSv1.0 ondersteunt.
- geen gebruik DNSSEC is EVIL. Een keer raden of sijmen.ruwhof.net DNSSEC ondersteunt.
Enige goed punt is gedateerde softwarebibliotheken.

Een niveautje hoger:
- Als vertrouwelijkheid van belang is (wachtwoorden, gevoelige informatie) dan is goede implementatie HTTPS van belang. Zou niet dan maakt het niet uit.
- Als deze "onderzoeker" hoog risico hangt aan niet versleutelen publieke info dan moet je 'm niet al te series nemen...

dat ligt er aan welke punten je vergelijkt en welke jij belangrijker vind. in mijn ogen doet de piraten partij het beter (het beste zelfs)

Welke beveiligingsupdate van jQuery wordt hier bedoeld?
Al jaren geen enkele non-functionele update gezien.

Autocomplete? Dat is wel erg achterhaald om dat nog te adviseren. Geen browser dit zich nog iets aantrekt daarvan.

Waarom zou je adviseren om TLS 1.0 uit te zetten op een site waarmee je zoveel mogelijk mensen wilt bereiken?
NCSC TLS beleid zegt ook niet dat het onvoldoende is. En uitzetten betekend nogal wat qua bereikbaarheid.

HPKP staat in deze lijst. Opvallend, dit artikel is vast niet gelezen door de onderzoeker:
https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead

Bij "geen beveiligingsupdates" denk ik aan security patches. Dit gaat meer over (encryptie-) configuratie en gebruik van functies.

Het grote gevaar van het hacken van servers via exploits en verkeerde beveiligingsinstellingen, en daarnaast targeted phishing en targeted malware attacks (niet te verwarren met targeted phishing). Niet alleen web servers zijn van belang, maar vooral ook mail servers met imap, mapi, mailbox storage.
Aan banners kun je soms zien welke versie wordt gebruikt, maar helaas hebben sommige open source besturingssystemen de gewoonte oude versies te patchen zonder het versienummer aan te passen, daarom moet je goed weten wat het resultaat betekent voordat je conclusies trekt. Het is mogelijk sommige mail servers zonder versie nummers te fingerprinten zodat wel achterhaald kan worden wat voor soort software er draait.

Het is mogelijk via banners en functietests mail servers non-invasief te testen. Bij het verbinden moet door de gecontacteerde mail server worden aangegeven welke ESMTP functies worden ondersteund. Als er bijvoorbeeld helemaal geen transport encryptie wordt ondersteund(*), betekent dat dat alle mail in platte tekst over het Internet gaat. Fantastisch voor ongenode meeluisteraars. Politieke partijen zouden anno 2017 helemaal geen mail zonder encryptie van zowel wachtwoord als content moeten ondersteunen.

(*) sommige firewalls en achterhaalde securitypolicies ondersteunen alleen puur SMTP. Het aanvalsoppervlak wordt hiermee verkleind, maar het nadeel van ontbreken van transport encryptie is groot.

Patchen zonder het versie nummer aan te passen behoort echt niet tot de zgn. 'best practices', doe maar eens een asafaweb scan voor een asp website. (errors-fail, http-only cookies, clickjacking waarschuwingen).

Men hoort het wel vaak roepen in het veld, maar het is een vorm van 'security through obscurity' en echt niet zoals het hoort te worden geïmplementeerd. Veel grote zorgen zijn echter af te serveren plug-in code en nog erger, verlaten code, die niet meer door de ontwerper(s) wordt onderhouden, of geobfusceerde stukken code zonder te weten wat het doet en te exploiteren fouten natuurlijk.

Servers geven de mogelijkheid om de server in kwestie zoveel mogelijk te laten zwijgen (niet geheel echter, want er zijn nog andere methoden om uit te vogelen met wat voor server men bijna zeker te maken heeft).

Maar buitensporige server info verspreiding (ook wel excessieve server info proliferatie genoemd) is ongewenst, evenzeer is het ongewenst, dat info van naamservers wordt verspreid (doe een DNS scan). Hee, daar draait zus en zo en daar kan een bind9 exploit kwetsbaarheid zitten. Meer iets voor de script-kiddies onder ons, maar toch. Dazzlepod scannetje draaien ook altijd zeer informatief (info mag niet gedeeld of tegen een website gebruikt)

Bovenstaand overzicht geeft ons geen inzicht over de stand van zaken aangaande input - output beveiliging, over inline scripting en actuele cloaking (verschillen tussen wat google ziet en wat google bot krijgt voorgeschoteld) en suspecte of kwaadaardige code, of onzichtbare iFrame code en externe links, die men beter kan blokkeren.

Het is slecht een moment opname van hoe de verschillende laagjes van web beveiliging kunnen zijn ingevuld en welke technieken hierbij zijn gebruikt - niet of de website elk moment kan worden gecompromitteerd. Een XSS exploit via webbug-code kan nog mogelijk zijn als de rest al is afgevangen. De dark hacker zoekt al de kleine wormgaatjes die hij onder de pet houdt na, maar gaat meestal voor het laaghangend fruit. Brute force aanvallen, php etc. etc.

Goede beveiliging is zeker zinvol, men gaat dan elders brute forcen of aan deuren en ramen rammelen. Of je moet te maken hebben met een gerichte aanval van specialisten. Daar helpt helaas vaak geen lieve moeder aan.

Dat de meeste website bouwers weinig kaas hebben gegeten van specialistisch website beveiligen en fouten jagen staat voor mij buiten kijf, maar dat is een geheel ander verhaal. Welk leuk om een en ander bovenstaand uitgewerkt te zien,
maar dan weten we nog niet voldoende welke website het eerst op omvallen zou staan of bezwijkt onder een automatische aanval.

Een goed beveiliger heeft meestal genoeg aan het doorlopen van een scan als deze https://aw-snap.info/file-viewer/ van Redleg om te zien waar ergens de schoen kan wringen. Dan als je het echt goed wil doen moet de rest ook allemaal nog in een afgegrendelde omgeving gaan testen. Maar als eerste ruwe indicatie hebben we per slot van rekening ten allen tijde de code-oren plat op de grond en horen als het ware de kwaadaardigheid of banner-pupjes ruisen. (Waar heb ik dat al eens eerder gezien of meegemaakt -oh dat was een zus en zo en daarom geblacklist?).

Nog een tip blijf met je website weg uit een mono-cultuur, alle (boze) vingers gaan richting Kwatta in dat geval. Variatie daar verhoogt je algemene veiligheid. En weet dat je geen last zal hebben van Nederlandse hackers. De pakkans in de eigen achtertuin is echt veel te groot om het zelfs te overwegen.

Blijf vooral veilig en secuur zowel offline als online, is de wens van

luntrus

Hoe zou je als burger dan een vraag stellen aan je partij, als jouw mailserver toevallig net geen encryptie ondersteund? Helaas is dat dus een mooi streven, maar niet werkbaar. STARTTLS bestaat niet voor niets.

Maar in het geval voor het onderwerp privacy/tracking is de website van de piratenpartij weer onveilig ten aanzien van trackers (zowel commerciële als overheid trackers) https://tk2017.piratenpartij.nl/?actie=1

Website is insecure by default
100% of the trackers on this site could be protecting you from NSA snooping. Tell piratenpartij.nl to fix it.

All trackers
At least 10 third parties know you are on this webpage.

- tk2017.piratenpartij.nl
-Google
-piratenpartij.nl
-Twitter
-scontent.cdninstagram.com
-Google
-Facebook
-Facebook
-Google
-shaaaaaaaaaaaaa.com -shaaaaaaaaaaaaa.com

Verder zijn vache-control en security-content-policy niet goed geïmplementeerd, alsmede deze meta secuity headers
. PHPSESSID heeft de host-only attribute gezet, maar verder staan alle cookies beveiligingsopties niet volgens best policy. Voor form autocomplete settings ook niet met secure settings.

Tracking dat je volgt cdninstagram.com fbcdn.net googleapis.com en gstatic.com
We blijven dus gevoelig voor de Amerikaanse overseers, misschien iets dat piratenparty niet zo ambieert,
maar ja we zitten in die infrastructuur nu eenmaal commercieel volledig ingebed en blijven voorlopig mee roeien.

Interessant te weten hoe de andere partijen scoren in deze twee opzichten (data verkregen via Tracker SSL extensie info & Recx Security Analyser v.1.3.0.4 extensie met site info voor https://tk2017.piratenpartij.nl/?actie=1

luntrus

Ik doelde op transport encryptie (zoals STARTTLS) tussen mail servers en encryptie tussen mail client en mail server. Met downgrade bestendigheid.

Ik doelde niet op encryptie in emails zoals PGP met burgers. Dat is een mooie toevoeging, maar het kan uiteraard niet een verplichting zijn, dat schiet het doel voorbij. Voor intern gebruik is het wel een goede zaak om meerdere redenen (zoals herkennen van mails met vervalste afzender), maar het vergt wel educatie.

starttls is onveiliger als tls/sll en gevoelig voor min aanvallen.