Dus? Met PHP is prima een veilige website te maken. Het bewijs kan ik leveren.

Blijft mooi hoe beveiligingsbedrijven afgeven op PHP. PHP is net zo goed als hun ASP.net die Imperva gebruikt. Het gaat nog steeds om de programmeurs die de software maken.

Drupal CMS is ook PHP, maar daar hoor je verdomd weinig van. Ja, heeft een kleinere fan-base, maar alle code wordt door een security team beoordeeld. Ook de plugins. En daar zie je bijna nooit meer security problemen.

TheYOSH

Met PHP is niets mis, mijn CMS is veilig, maar daar werken maar een handje vol websites mee.
En de meeste websites gebruiken tegenwoordig WordPress, dus logisch dat deze ook het meeste worden aangevallen.

Een CMS waar maar een handje vol websites mee werken geeft ook geen enkele garantie. Daar hebben over het algemeen te weinig ogen naar gekeken en zit vol met kwetsbaarheden.

Naar aanleiding van de opmerkingen over php en professionaliteit
zoekende en kijkende naar php sites.
Stuitte ik ineens op deze in Nederland gehoste mysterieus anonieme (php) security site.

Kijk naar het poppetje op deze anonieme site
http://www.malwareurl.com/index.php

Kijk nog een keer naar het poppetje op deze meer bekende site
https://www.certifiedsecure.com/about

Toevallig niet?

http://www.malwareurl.com/index.php
"FIGHTING MALWARE AND CYBER CRIMINALITY"
Volledig anoniem
http://www.malwareurl.com/contact.php

Wat is dat voor security gerelateerde geheimzinnigheid?
Wat kan doorvoor de reden zijn?
Security?

Heb het rapport gelezen en ik mis een nuance door de te korte samenvatting die securitynl geeft en de nogal ruime interpretatie van enkele lezers. Ik bedoel met name bij de laatste zin 'Daarnaast is WordPress ook op de programmeertaal PHP gebaseerd'.

In het rapport staat ook dat aanvallen zich vooral richten op PHP gebaseerde applicaties. De oorzaak daarvan staat er verder niet bij. De oorzaak is ook niet iets wat je uit statistieken op basis van firewall reports kan opmaken, het is niet dat de criminelen erbij zetten dat ze geen verstand van asp shells hebben of dat ze meer thuis zijn in php.

Ja men zou dergelijke WP websites met onveilige plug-ins en vaak ook met gebruikers enumeratie en directory listing aanstaand als vreselijk veiligheidsrisico moeten gaan aanmerken. Dit zijn sites met grove onveiligheid door incompetentie en onachtzaamheid.
Net als een truck van de weg dient te worden gehaald met te gladde banden en andere technische gebreken, hoort zo'n site die alles en iedereen van het ene op het andere ongenblik kan infecteren niet langer op het Internet thuis en moet een browser of aan AV dienst een veiligheidswaarschuwing afgeven. Ik hoor de protesten van de onwetende internetgebruikers al, ze waren toch eeuwenlang wel veilig genoemd. Onbenul en onwetendheid regeert meestal hier.
Maar nee, dat doet men pas als de site evident geinfecteerd is, dus na het feit, en al SEO spam, adware en allerlei andere soort van narigheid aan het spuien is. Ja, beste mensen, men wacht tot men het account kan suspenden of beëindigen om zo'n site dan vanuit het internet graf nog verder geld op te laten brengen via ads en tracking. Dus wil men deze expliciet onveilige websites eigenlijk wel kwijt of laat men de website eigenaars, admins en hosters liever in zalige onwetendheid? Ik vraag het me af. Iemand die wil reageren? Volgens mij is dit een belangrijke discussie!

Ij heb niet gereageerd omdat ik het rapport met de achtergrond niet zo goed kan plaatsen. Het is een service bedrijf gespecialiseerd in security /monitoring-detectie/ met een aantal klanten. Daar moet hun data vandaan komen. Wat doen die wordpress sites daar met normaal verwacht gebruik? ZIjn het commerciele proffesionele bedoelde sites of is dat vrije tijd invulling van werknemers.

Dat raakt jouw vraag.
De truck is een commercieel professioneel bedoeld gebruik. Daar horen overeenkomstige voorwaarden bij.
Nu heb ik een thuishobby met b.v. een eigen terrein waar het gebeurt. Moeten daar de zelfde voorwaarden voor gelden?

Wanneer dat eigen terrein niet is afgesloten, dan gelden daar de regels voor openbaar terrein.

Ik heb geen zin verzeild te raken in een discussie dat een vrachtwagen met slechte banden doden kan veroorzaken dus van de weg moet en een website minder risico oplevert. Net zo min als een over dat de vrachtwagenchauffeur niet iedere dag controle krijgt van de politie op zijn banden, rusttijd, lading en wat allemaal nog meer.

In onze samenleving is de eerste verantwoordelijke de persoon die iets doet zelf. Of het nu een bestuurder is die te hard rijd, een huiseigenaar die zijn huis niet op slot zet, een ouder die zijn grut van 5 alleen laat buitenspelen, een koper die een contract aangaat maar geen centen heeft, een winkelier die een website opzet of een bedrijf dat nog systemen met xp draait. Regulerende wetgeving draait vooral om het voorkomen van groot leed (lees dood/levensbedreiging/(zwaar) letsel) of instabiliteit van de samenleving. Om dat vervolgens ook nog te handhaven door bevoegd gezag vraagt financieel en tijdtechnische grote offers.

Het is makkelijk om voor verantwoordelijkheid te wijzen naar de wetgevers of dienstverleners. De eigenaren doen niets dus moet een ander wat doen en die doen zogenaamd niets. Er zou wetgeving moeten zijn tegen brakke websites? Hoe wil je dat zinvol invulling geven? Je moet de laatste versie van software draaien? Als er 10 fouten in software zijn gevonden mag je die niet meer gebruiken? Je mag alleen software draaien die goedgekeurd is door de NVVH? Een bedrijf waar je webruimte koopt is verplicht een security scan uit te voeren op al je data die je in die webruimte plaatst? Als die scan, bedacht door een of andere bedrijf, meld dat de data er verdacht uitziet moet de dienst ter stond worden afgesloten? Je mag alleen een website op laten zetten door een bedrijf met personeel dat minimaal een iq van 150 heeft?

Het is een illusie te denken dat als je extra regels gaat invoeren het probleem wel weg gaat en er geen andere problemen bij komen. Het is een illusie te denken dat als je alles maar gaat reguleren en aan banden gaat leggen het een prettigere samenleving zal zijn.

Hoe vaak worden eigenaren van brakke websites werkelijk aangesproken door de personen die er last van hebben? Bijna nooit. Begin daar eens als samenleving: stel eerst zelf eens de juiste personen aansprakelijk, in plaats van te roepen dat een ander partijen het maar moet opknappen of al hadden moeten voorkomen. We leven niet in de wereld van minority report.

De sites met de evidente gebreken zie ik maar al te vaak en het zijn echt niet alleen maar huis-tuin-en-keuken sites, die overigens bezoekers op eenzelfde wijze infecteren. jQuery wordt erop gegooid en er wordt noot meer naar om gekeken. Er lopen mensen op de werkvloer rond die van website veiligheid echt weinig kaas hebben gegeten, ze hebben niet meer kwalificaties omdat er te weinig budget is voor een goede kracht en er zwaar onderbetaald moet worden. Dus liever 145 eurie naar een freelancer om de boel eenmalig op te schonen. Ik herinner me nog de dagen van een Hitman Prootje a raison van 75 euro eens per twee weken. Er wordt wat af gemodderd.

Zou jij willen dat criminelen je adresgegevens makkelijk in handen kregen? En waarom zeveren over een poppetje en mysterieusheid?

Dat is toch een goede indicatie dat je met rommel te maken hebt?
Als je de websites in twee categorieen indeelt, degenen die met behulp van PHP gemaakt zijn en degenen die dat niet
zijn, dan zul je in de PHP categorie beslist meer applicaties met problemen tegenkomen. Domhedenzoals het automatisch
vullen van variabelen vanuit allerlei bronnen zoals het environment, de query parameters etc zijn inmiddels default wel
opgelost, maar de functie mysql_query is not altijd niet verwijderd.
Een gemakkelijke 1e check na uitpakken van een PHP applicatie is nog altijd:

if grep -qR mysql_query sourcedir
then
rm -rf sourcedir
fi

Als iedereen dit even intikt voor hij een PHP applicatie in gebruik neemt zijn we een stuk verder!

Goed dat een heleboel technische IT dit leest en zo hoort het ook.
Neem eens een willekeurige WP website met PHP met problemen en check die eens hier: https://hackertarget.com/wordpress-security-scan/
Veelal zijn de plug-ins niet geupdate of is de plug-in code zelfs verlaten door de ontwikkelaars. Een check op kwetsbare libraries hier voor jQuery geeft ook nog heel wat onveilige uitkomsten: retire.insecurity.today/#

Trouwens de asp sites kunnen er ook wat van. Niet veel asafaweb scans zien passeren, die geen waarschuwingen laten zien.Vooral het scannen van mainland China sites kan enerverend zijn (custom error: Fail). Veel Microsoft sites met
excessieve server header info proliferatie, maar vooral kwetsbaar voor clickjacking. De overall security header situatie is helemaal droevig. Check maar eens hier: http://cyh.herokuapp.com/cyh
Zet alstublieft de boel toch wat beter dicht!

Ik ben het met de reagerende eens dat je als samenleving best degenen die dergelijke onveilige rommel in de lucht houden mag aanspreken, Misschien moet je als bedrijf een risico verzekering hiervoor afsluiten, maar dan zal je ze toch eerst moeten laten zien en nu worden overal dergelijke sites die elk moment narigheid kunnen geven alleen maar "na het feit" gedetecteerd. Er zou aangegeven moeten worden: "Website eigenaar u brengt uw bezoekers in groot gevaar door uw onveilige toepassingen". En wie dat moet gaan doen, daar valt wel over te discussiëren lijkt me. Dan is er ook nog het probleem van export restrictie waardoor veilige code in een bepaald land niet voorradig is of nog niet is. Export restricties kunnen ook een verlammende rol spelen waar website veiligheid in het geding is. Ieder moet zijn verantwoordelijkheid nemen. Ook bij het IT onderricht, als proctor zie ik veel te weinig aandacht voor veiligheid. Security is vaak nog een ondergeschoven kindje voor de gewone ontwikkelaar.

Leuk om even naar te kijken, de vos hier die hier passie preekt.
Hier volgt het resultaat van de asafaweb scan van imperva's eigen ASP website.

Zie: https://asafaweb.com/Scan?Url=www.imperva.com
Waarschuwing 1.
Excessieve web server header info proliferatie.

Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 5.0
Configuring the application to not return unnecessary headers keeps this information silent and makes it significantly more difficult to identify the underlying frameworks.

2. HTTP Cookie's Only waarschuwing:
It looks like 2 cookies are being set without the "HttpOnly" flag being set (name : value):

visid_incap_2439 : zglrmeAhQGXXXXXXXXXXXXXXXAAAAAAwl92AAoaSNsh3/q1xTfG3
incap_ses_143_2439 : 8os6KUXXXXXXXXXXXXXXXXXXXXXXXxxAAIlpKf3G8kAZz+fyJ2nLgZw==
Unless the cookie legitimately needs to be read by JavaScript on the client, the "HttpOnly" flag should always be set to ensure it cannot be read by the client and used in an XSS attack.

3. Waarschuwing voor Clickjacking.
It doesn't look like an X-Frame-Options header was returned from the server which means that this website could be at risk of a clickjacking attack. Add a header to explicitly describe the acceptable framing practices (if any) for this site.

Dus zoals het spreekwoord luidt: "Verbeter de wereld, maar bein altijd eerst bij uzelf".