Omdat? Indien goed geprogrammeerd, is het gewoon veilig.
Indien slecht geprogrammeerd is alles onveilig.

Menige grote site draait gewoon zonder problemen op PHP, dus daar ligt het niet aan.

Kijk naar Tweakers, wikipedia bijvoorbeeld. Grootste gedeelte is allemaal PHP en werkt zonder enig issue.

Wederom een nutteloze bijdrage Neb.

"Joomla, stop ermee!" zou meer binnen de context liggen en ook dichterbij de waarheid.

ABN? https://fondsen.abnamro.nl/nieuw/index.php

Stop met Java EE docker containers Virtualisatie sql en meer. Wat ik bij ded grote bedrijven / organisaties gezien heb is dat ze de informatieveiligheid niet op orde krijgen...Dat ligt vast aan de tools (ahum)..
Advies: je kunt beter bij een gedegrdn ontwerp en structuur beginnen met security by design en prvacy by design in een pdca cyclus. Al die hobbyisten die geloven dat het coderen het zaligmakende werk is, moeten nog veel leren.

@Karma4 & Neb Poorten e.a.

Joomla en Word Press niet juist geconfigureerd met kwetsbare thema's & plug-ins, op websites met af te serveren jQuery bibliotheken, met sri-hashes niet gegenereerd, zonder de noodzakelijke security headers, met DOM-XSS kwetsbaarheden. Kwetsbaarheden net zo variabel als Engelse drop en erger.

Vaak gehost op onveilige naamservers en webservers met cookie issues en server info proliferatie om een begin van een hele waslijst narigheid op te noemen.

Wanneer gaan we deze rotzooi, want dat is deze amateuristische zooi, eens niet langer meer tolereren? Neerhalen en pas weer toelaten als alles enigszins basaal op orde is en niet langer een gevaar vormt voor de internetgebruikers en de makers zelf? Waarom willen we dat niet met zijn allen????????

Maar dat hoef je van Google, Cloudflare, Akamai enz. niet te verwachten. Zal wel ergens mee conflicteren?

Ik vraag me steeds af waarom men een a priori onveilige infrastructuur prefereert boven een veilge(r)?!?

Ik kan me de nooit duidelijk gemaakte antwoorden voorstellen, net als waarom een ge-resource-engineerd stuk IBM code uit 1992 nog het Internet a la 2017 onveilig moet maken (de recente SMB v 1 ellende) van wege wat plug-en-play beschikbaarheid. Nu net weer het SMBloris-gat.....

Zo zullen mensen die website beveiliging begrijpen, zich blijven verbazen. Karma4 gooit het nogmaals op de tooltjes- en dozen-schuivers en de invloed van n00b CEO's etc. als oorzaak en niet luisteren naar de beveiligers. Neb Poorten geeft PHP de schuld en ik zeg de meeste narigheid hebben we te danken aan slecht geimplementeerde JAVASCRIPT, de "hulk"van alle kapstoktalen en soms zie je "zijn shirtje weer eens op zwellen" na een vergeten semi-colonnetje of vleeshaakje...(iron. bedoeld hoor).

Maar hoe dan ook, er verandert n i e t s.

luntrus (vrijwillig en onafhankelijk website foutenjager).

Mijn beste Neb Poorten,

Juist als je zorgt voor gedegen monitoring en logs-analyse en juiste server implemtatie, DNS etc. OK.

Javascript kent nogal wat errors Scan maar eens met jsunpack en lees vervolgens de ellende na op StackOverflow.
Unsafe inline scripting, SRI hashes niet gegenereerd en Afraid dot org en Cloudflare zuinigheid op veiligheid zorgt dat je voor je het weet vogelvoer bent voor SEO hackers, FakeJQuery enz. Ik zie het alleen maar toenemen in de praktijk van alle dag en ik heb duizenden en duizende scans over veertien jaar op mijn netvlies staan.

Maar juist bij ASP.NET websites, zie ik nogal wat bij een asafaweb scannetje. Bijna allemaal kwetsbaar voor clickjacking bijvoorbeeld. "Luid babelen" van servers, ook vaker gezien dat niet aangetroffen. Daar is een hele grote inhaalslag te maken.

Kijk eens naar China met hun Microsoft webserver mono-cultuur. Heerlijk toch voor die NSA en andere spooks....

luntrus

Dat is het idee van de codeklopper dat hij alles perfect doet. Dank je dat je het toegeeft.
Zodra het in handen van testers beheerders komt doen die er zaken mee die jij niet voorzien hebt. Dan heb je het nog niet eens over al die zaken die je niet wist, niet wist totdat het te laat is. Dat is gangbaar voor elk tool.

@karma4

En ook kijkt de gemiddelde code-inklopper ook niet of tie later geen Spamvertiser alerts krijgt.
Hier krijgen we weer gelijk en zo zijn er bijv. ontelbare gelijkaardige Emerging Threats Spamvertiser IDS alerts te vinden.

Voorbeeldje en niet voor zo'n kleine website of van een of ander 'amateurtje:
https://www.virustotal.com/pl/url/a24b27672126105b7af2c5744070666dcf80c5d79d2babab3da65d42f03610a1/analysis/1501015762/

Met alerts door CleanMX: http://support.clean-mx.de/clean-mx/view_portalscontent.php?url=http%3A%2F%2Fnodecheats.com%2Fcommunity%2Fshowthread.php%3Ftid%3D437%26amp%3Bpid%3D515%23pid515

Voor dezelfde IP - let op. het misbruik op GoDaddy: https://www.scumware.org/report/43.255.154.97.html

Af te serveren jQuery bibliotheek voor: -http://nodecheats.com
Ontdekte bibliotheek:
jquery - 1.11.3 : (actief 1) -http://nodecheats.com/assets/js/jquery.min.js
Info: Ernst: gemiddeld.
https://github.com/jquery/jquery/issues/2432
http://blog.jquery.com/2016/01/08/jquery-2-2-and-1-12-released/
(actief) - van de bibliotheek werd vastgesteld dat het actieve runcode bevat.
1 kwetsbare bibliotheek gedetecteerd.'

Wat we dus constant lopen te preken hier, is waar, maar het wordt niet voldoende opgepakt.
Niet opgepikt in de opleiding en ook niet later in de praktijk, men is er vaak blind voor
of houdt er de ogen en oren voor dicht en de mond over,
net als de spreekwoordelijke horen-, zien- en zwijgen-aapjes.

luntrus