@Ned Poorten,

Hou toch eens op met bashen van een taal, het is niet de schuld van de tool, dat ontwikkelaars fouten maken.
Ook PHP is veilig te maken. Als je niets vertrouwd en wat meer jaartjes ervaring hebt in secure web applicaties te maken.

Maar laat wat Java ontwikkelaars, die netjes hun JAVA certificaten hebben gehaald een site maken. En je hebt in eens een overheid die porno host of andere site's gaat aanvallen.

Kortom, mensen maken in elke taal fouten en zo zal het ook blijven.

[q]Met een Mercedes rijd je beter en veiliger dan met een Trabant van karton. [/q]
Je bent nog steeds afhankelijk van externe factoren.
Als een vrachtwagen met volle snelheid om je inrijd, maakt het niet veel uit of je in een Mercedes zit of een Trabant.

Als de bestuurder van de Mercedes, geen rij ervaring heeft een de bestuurder van de kartonne Trabant wel een paar jaar, mag je nog steeds er vanuit gaan dat de trabant bestuurder veiliger door het verkeer heen gaat, dan de Mercedes bestuurder.

Klopt, maar er is ook geen beveilings risico, als de computers uitstaan. Die komt pas weer, als de stroom terug komt.

De ervaren bestuurder zou weten, dat die zijn band moet vervangen. Aangezien een lekke band een aardig risico is. Lastiger sturen, moeilijker om goed te remmen etc etc.

Die moet je eens vaker gebruiker.....

Maar ook PHP is gewoon veilig te maken. Probleem is alleen vaak dat er te veel legacy code in de applicatie zit waarna er problemen ontstaan.
Er zijn grote grote bedrijven die gewoon goede code schijven en maken. Voorbeelden genoeg op Internet te vinden.

Toch jammer dat dit soort OpenSource producten, waarvan iedereen de code kan zien, zoveel grote fouten bevatten.

Hangt er vanaf, hoe je je banden onderhoud en welke banden je er onder zet.
Hangt er vanaf wat je er mee wilt doen. Mercedes kost een vermogen, is duur in onderhoud. Trabant, is goedkoop, en onderhoud is een stuk gemakkelijk.
Als ik puur van A naar B moet en dat is maar een paar km verder, waarom zou ik dan geen Trabant kunnen nemen, als dit mij een vermogen bespaard?
Moet ik van Assen naar Maastricht iedere dag... Dan kan ik inderdaad waarschijnlijk beter een Mercedes nemen.

Ofwel het licht nog steeds aan je requirements en beheerders/programmeurs hoe goed of hoe veilig het is/wordt.

Omdat Drupal een security update uitgeeft, blijft het problematisch? Het lijkt me vrij normaal dat er beveiligingsupdates komen of hoeft dat niet in Magnolia CMS? o wacht... Er komt gemiddeld 1x per 1,5 maand een versie vrij... en kijk nou... deze bevatten ook beveiligingsupdates:
https://documentation.magnolia-cms.com/display/DOCS/Release+notes+for+Magnolia+CORE+5.5.3#ReleasenotesforMagnoliaCORE5.5.3-Security-relatedandotherchanges

Wat is het verschil? behalve dat de Magnolia CMS developers 2x zo duur zijn en dat er geen classificatie aan de beveiligingsupdate wordt gegeven?

Hé je hebt een licht straaltje gezien. misschien is er hoop. Wat is gratis en voor niets en hoef je niets meer aan security te doen. Klein tipje: Begint met L eindigt met x. Mag ook met O en e.

http://fortune.com/2017/03/03/daimler-recall-mercedes/

Daimler AG said it will recall one million newer-model Mercedes-Benz vehicles worldwide due to the risk of fire, after 51 fires were reported.
The German company said no injuries or deaths were reported relating to the vehicles that it will begin recalling in the U.S. market in July when parts become available.

Voor verbitterde mannen die zich in hun standpunten hebben ingegraven is hoop verkeken.

Ga eerst de ontwerpers eens leren coderen met beveiliging en veiligheid op het netvlies.
Daar ontbreekt het nu nog vaak aan. Veel security through obscurity overal
en beveiliging als vaak 'te dure' sluitpost op de begroting....

Zo maar een lukraak code-voorbeeldje, wat me te binnen schiet
- fout -www.emailservicehelp.com/javascripts/bootstrap.js benign (104 malware links op site) houdt in - PHP call to relatively undefined function, probably function in a different namespace.[/quote] info credit StackOverflow's.

Bij op PHP gebaseerd CMS gaat er veel te vaak ook op andere punten wat mis.
User Enumeration ingesteld, Directory Listing enabled, My SQL wachtwoorden buit te maken.
Bind versies op naamservers aangegeven (info-proliferatie). DNS fouten.

Doe eens een scannetje op een domein bij https://threatintelligenceplatform.com/
en je ziet waar ik het over heb.

http://www.domxssscanner.com/ scan resultaten spreken ook vaak boekdelen,
vooral na een jsunpack scannetje op de kwetsbare code.

Als je in het eerste jaar van je studie je zelf javascript je eigen moet maken
en in het derde jaar een klam verhaaltje opgedist krijgt over black, grey & white hackers.
Ja, wat willen we dan eigenlijk?

Security exclusief houden voor de happy few van het kleine kringetje experts voortgekomen uit Technische IT en de
paar hackers met voldoende verworven relevante kennis die een aantal overheidsspooks moeten faciliteren om de grote massa in zalige onwetendheid te houden. Willen we dat?

Hou toch op met wederkerig bashen en ga aan wat fundamenteel fout zit wat doen.

Maar ik ben bang dat dit niet getolereerd zal worden. Te veel belangen achter de schermen, die zoiets wel met de mond belijden, maar niet echt wensen. Zo dubbel allemaal, die beveiligingswereld.

luntrus

Dat is de misvatting waardoor al die security zo rampzalig is. Zo lek als wat en voldoet aan geen enkele richtlijn voor informatiesecurity Linux is wat dat betreft één brok ellende. Toon mij eens een nette omgeving in het wild in de big data setting. Ik heb er veel gezien en overal is er dat zelfde gedoe.

@Neb Poorten,

Hangt er maar vanaf, wat je eraan hangt aan admin & manager apps met default wachtwoorden, en wat te denken van webservers met gevaarlijke javascript api's die te manipuleren zijn voor server side injectie!

Zogenaamd client XSS versus server side SQL injectie. Hoeveel naamservers zwijgen nog niet over server versie info? SQL password proliferatie. Meten is weten, veilig coderingspraktijken gebruiken is zich veilig weten.

Ergens iets onderin het netwerk hangen dat (nog) kwetsbaar is voor DROWn en de hele kaboodle is ook gelijk kwetsbaar, ook de zogenaamd niet kwetsbare servers hogerop in het netwerk.

En je hebt niet altijd alle omstandigheden zelf in de hand. Een onveilig hostertje ergens of slecht geconfigureerde cloud-dienstje en je kunt al vogelvoer zijn. Alles wat ik zelf niet check, bijvoorbeeld met grunt op node,js vertrouw ik niet (ten volle).
Afvoeren wat afgevoerd moet worden, basta!

Was het maar allemaal zo veilig als gepredikt wordt of men zelf denkt of vermoedt, dan waren er heel wat minder veiligheidsincidenten. Karma4 heeft wat dat betreft wel het gelijk aan zijn kant, terwijl ik onverlet laat dat client-server en server-client monitoring en IDS niet een verplicht nummer moet zijn, altijd natuurlijk!

Zodra je een dienst op gaat aanbieden ben je vatbaar en moet je updates installeren. Of dat nu een OS update is, een service update, of een Applicatie update. Dit is nu een webserver, desktop of file server is.

Zodra je dat niet doet, heb je gewoon een groot risico draaien. En je kop in het zand steken omdat er bijna geen malware is, is gewoon dom en gevaarlijk.

En als we het toch hebben over WIndows 10 IOT..... Dat is ook een afgeschermde omgeving, waar de aanvalsvector aanzienlijk verminderd is. Je installeerd immers alleen wat je nodig hebt.

En dan hebben we dit, wat hier beschreven staat.
Waarom doen we het eigenlijk?
Waarom ontdekken we onveiligheid als anderen ons alleen maar verwijzen naar RTFM?

Je ontdekt onveiligheid, het niet volgen van best practices etc. etc.
Niemand doet er vervolgens iets mee. Is dat niet enorm frustrerend?

Lees: https://medium.com/@homakov/why-it-sucks-to-be-a-security-researcher-8a1d17fbffe8
Info link credits go to Secure Login reporter: Egor Homakov

Hebben jullie inmiddels dat gevoel ook?