image

Gisteren gepatcht Drupal-lek nu al actief aangevallen

donderdag 26 april 2018, 09:36 door Redactie, 35 reacties

Een zeer ernstig beveiligingslek in het Drupal-platform dat gisterenavond via een noodpatch werd verholpen wordt nu al actief aangevallen, waardoor meer dan een miljoen websites risico lopen. Dat laten de ontwikkelaars weten. Via het lek kan een aanvaller volledige controle over websites krijgen.

De noodpatch van gisteren is een aanvulling op een noodpatch die op 28 maart verscheen. De kwetsbaarheid van 28 maart wordt sinds 11 april actief aangevallen. Alle Drupal-websites die de eerste noodpatch sinds 11 april niet hebben geïnstalleerd moeten volgens experts als gehackt worden beschouwd. Vorige week waarschuwde een securitybedrijf nog dat gehackte Drupal-sites door een botnet worden gebruikt voor het delven van cryptovaluta en het uitvoeren van ddos-aanvallen.

Beheerders van Drupal-sites krijgen het advies om meteen te updaten naar Drupal 7.59, 8.4.8 of Drupal 8.5.3. Drupal 8.4 wordt niet meer ondersteund, maar vanwege de ernst van de kwetsbaarheid heeft het ontwikkelteam besloten om voor deze versie toch een update uit te brengen. Om de noodpatch van gisteren te installeren moet eerst de noodpatch van 28 maart zijn geïnstalleerd.

Reacties (35)
26-04-2018, 10:42 door meinonA
Om de noodpatch van gisteren te installeren moet eerst de noodpatch van 28 maart zijn geïnstalleerd.

Als je die niet geïnstalleerd hebt moet je maar een andere baan/hobby gaan zoeken.
26-04-2018, 11:53 door karma4
Zal wel een vraag zijn of gemeente delft op tijd was.
Gemeentelijke molens draaien langzaam.
FOSS zal het wel weten
26-04-2018, 23:06 door -karma4
Door karma4: Zal wel een vraag zijn of gemeente delft op tijd was.
Gemeentelijke molens draaien langzaam.
FOSS zal het wel weten

Dat was Kraak: https://www.security.nl/posting/559592/#posting559618.
27-04-2018, 07:51 door Anoniem
PHP is meer een bijeengeraapt zooitje, dan een programmeertaal aldus Jeff Atwood eens.

Ergo: liever geen op PHP gebaseerde architectuur gebruiken.

Zie dit dus liever niet: https://www.drupal.org/node/1880590

Krakatau hier zal het wel met mij eens zijn, anderen ook als ze nadenken over alle ellende van dien.

"PHP, weg ermee!".

luntrus
27-04-2018, 12:01 door Anoniem
Door Anoniem: PHP is meer een bijeengeraapt zooitje, dan een programmeertaal aldus Jeff Atwood eens.
Het probleem is meer dat PHP programmeurs een bijeengeraapt zootje zijn.
Je kunt best goed programmeren in PHP maar helaas is "PHP voor dummies" het level waarop de meeste mensen
werken. Als je dan een groot project met vele contributors hebt dan weet je zeker dat er keer op keer problemen zijn.

Als er plugins ondersteund worden, hou dan maar helemaal op. Dan heb je het niet meer in de hand.
27-04-2018, 13:18 door Krakatau
Door Anoniem:
Door Anoniem: PHP is meer een bijeengeraapt zooitje, dan een programmeertaal aldus Jeff Atwood eens.
Het probleem is meer dat PHP programmeurs een bijeengeraapt zootje zijn.
Je kunt best goed programmeren in PHP maar helaas is "PHP voor dummies" het level waarop de meeste mensen
werken. Als je dan een groot project met vele contributors hebt dan weet je zeker dat er keer op keer problemen zijn.

Als er plugins ondersteund worden, hou dan maar helemaal op. Dan heb je het niet meer in de hand.

Nee, als er na alle kritiek iets duidelijk is, dan is het wel dat dit bij PHP niet alleen het probleem is. Om het vriendelijk en rustig te zeggen.

PHP is a 'grown' language rather than deliberately engineered, making writing insecure PHP applications far too easy and common. If you want to use PHP securely, then you should be aware of all its pitfalls.

https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

As a result, about 79% of all PHP websites run at the moment on a vulnerable PHP interpreter.

https://blog.ripstech.com/2017/security-flaws-in-the-php-core/

What you're seeing is not Photoshopped. This is an actual photo of a real world, honest to God double-clawed hammer. Such a thing exists. Isn't that amazing? And also, perhaps, a little disturbing?
...
Remember the immediate visceral reaction you had to the double-clawed hammer? That's exactly the reaction most sane programmers have to their first encounter with the web programming language PHP.

https://blog.codinghorror.com/the-php-singularity/
(met dank aan @luntrus)

PHP is the lone exception. Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can’t even point out any single damning thing, because the damage is so systemic.

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Door Anoniem: PHP is meer een bijeengeraapt zooitje, dan een programmeertaal aldus Jeff Atwood eens.

Ergo: liever geen op PHP gebaseerde architectuur gebruiken.

Zie dit dus liever niet: https://www.drupal.org/node/1880590

Krakatau hier zal het wel met mij eens zijn, anderen ook als ze nadenken over alle ellende van dien.

"PHP, weg ermee!".

luntrus

@luntrus Inderdaad!
27-04-2018, 19:01 door Anoniem
A bad workman blames his tools...
27-04-2018, 23:31 door Krakatau
Door Anoniem: A bad workman blames his tools...

A good craftsman knows his tools...
28-04-2018, 09:30 door karma4 - Bijgewerkt: 28-04-2018, 09:32
]
Door Krakatau:
Door Anoniem: A bad workman blames his tools...
A good craftsman knows his tools...
Er hoort bij: "a fool with a tool still is fool".
Een goede specialist kan kwaliteit voor elkaar krijgen met slecht gereedschap.
Een prutser krijgt niets voor elkaar ook niet met het beste gereedschap


Het zegt waar je in de dagelijks werkzaamheden mee te maken hebt. Draaiend houden van machines en systemen waar anderen het in meeste in PHP aanleveren. Ik zie de frustratie over de slechte aangeleverde kwaliteit zich ophogen. De bazen opdrachtgevers zijn er toch blij mee en het gaat natuurlijk gewoon door.
Je kiest ervoor om af te gaan geven op de tools. Je zou eerlijker zijn om je er niets van aan te trekken of een ander baantje te gaan doen. Het is kennelijk niet jouw taak om de kwaliteit te evalueren.


PHP gebouwd als open source https://en.wikipedia.org/wiki/PHP OSS moet toch perfect zijn....
"PHP development began in 1994 when Rasmus Lerdorf wrote several Common Gateway Interface (CGI) programs in C"
CGI programma's zeker als die geen afgescheiden containers hebben (gescheiden service accounts) zijn in de basis kwestbaar. De bashshell shock is een zelfde soort basale ontwerpfout op het vlak van wat gescheiden services met apart rechten horen te zijn..

https://en.wikipedia.org/wiki/Rasmus_Lerdorf Ik zie het verhaal van mongo-db (notoir bekend om vele massale datalekken)
De code injection mogelijkheden op vele vlakken zijn standaard in vele interpreters.

Op dat vlak van eerste taal leren ...PHP zijn we het eens.
Nee het zou niet als eerste te leren taal gebruikt moeten worden. Het is te inconsistent van opzet. Edsger Dijkstra kwam daarvoor met Algol. Een theoretisch schone taal goed om de basis te leren. Wat er in de praktijk gebruikt werd Fortrnan Cobol C Assembler-s scripts en alle vernieuwingen kwam later wel.

Autorijden kan je leren in een golfje die basis is voor vele autos en vernieuwingen uitwisselbaar.
Je word pas goed met het vele doen niet met een paar proeflesjes. Dus eerst wat ander zaken leren dan dit dan pas na jaren en vele projecten de kwaliteit bekijken. Met die paar uurtjes introductie nu en dat als gecertificeerd specialist zien blijf je een probeer en leren van fouten aanpak hangen (trial & error).

Wat nog ontbrak was de IBM link. [url[http://www.redbooks.ibm.com/redpapers/pdfs/redp3639.pdf[/url] oud en achterhaald want uit 2003. Een IDE wordt onterecht verafschuwd https://www.ibm.com/developerworks/library/os-php-ide/index.html. Het lijkt soms wel de ponskaartentijdperk als je ziet hoe er gecodeerd wordt en git als de oplossing voor versiebeheer genoemd wordt.


Open source en gemeenten: https://www.ezcompany.nl/projecten/drupal-voor-gemeenten
gemeente delft: https://www.drupal.org/node/2815083 https://amsterdam.piratenpartij.nl/piratenpartij-stelt-vragen-vrije-open-source-software-waterschap-amstel-gooi-en-vecht/
Sorry luntrus, ik zie hier een ideologie conflict. Ik heb raakvlakken met dit deel maar het is niet mijn hoofdaandachtsgebied.

Wel heel komisch, de onderbouwing en wijze van krakatau om tegen PHP te keer te gaan kan hij niet hebben als het zijn eigen tools zijn die volgens heem aangevallen worden.
28-04-2018, 12:20 door Krakatau - Bijgewerkt: 28-04-2018, 12:31
@karma4 Het begint wel wat voorspelbaar te worden nu. En doorzichtig. De kleine denker karma4 die zo graag grote denkers aanhaalt bij zijn monologen. En die complotten denkt te zien die niemand anders ziet / kan zien.

Je keert je nu ook al tegen de eminente luntrus?

Voor wat betreft het afkraken van tools, daarvoor moet je natuurlijk wel een security gerelateerde reden hebben. Niet zoals jij een verkapt commerciële reden. Het zal de invloed van Microsoft en haar methodes wel zijn.
28-04-2018, 18:11 door karma4 - Bijgewerkt: 28-04-2018, 18:17
Door Krakatau: @karma4 Het begint wel wat voorspelbaar te worden nu.
....
Je keert je nu ook al tegen de eminente luntrus?
..
Voor wat betreft het afkraken van tools, daarvoor moet je natuurlijk wel een security gerelateerde reden hebben. Niet zoals jij een verkapt commerciële reden. Het zal de invloed van Microsoft en haar methodes wel zijn.

Krakatau ik heb het niet over Luntrus. Jij bent degene die zo fel tegen php is.

Ik heb niets met microsoft zoals jij verondersteld.
Mijn aandachtsgebied is dwh bi analytics big data. Daar heb ik behoorlijk last van slechte security met name oss linux. Dat wordt sterker als je er een web service er aan koppelt. Met de voeten in de modder met realisaties. Wat ik aanhaal en naar verwijs zijn security gerelateerde zaken.

Met wat een beheerder (jij) die niet verder kijkt dan wat hem toevallig dwars zit is een klein deeltje van het grotere geheel.
Het ongenuanceerd afgeven op dat kleine deel is eerder belemmerend voor een betere security dan dat je bijdraagt aan iets opbouwends. Sterker je giftige houding is een reden dat er nauwelijks wat kan veranderen.

Waarom reageer je zo getergd als er iemand zegt dat met linux beheer er zeer slechte security neergezet wordt.
Als dat zo is moet je daar niet een complottheorie van microsoft promotie bij gaan verzinnen. In dat geval heb je een geloofsovertuiging die je verblind.
28-04-2018, 21:47 door Anoniem
Wat.ik de laatste jaren tegenkom aan onveiligheid op PHP gerelateerde cms als Wordpress etc. stemt niet tot vrolijkheid. Vooral plug_in code en ook verouderde kernelcode. Af te voeren jQuery bibliotheken. Soms kan het nog wat tegengegaan worden door instellen van Security Headers etc.
luntrus
29-04-2018, 06:44 door karma4
Door Anoniem: Wat.ik de laatste jaren tegenkom aan onveiligheid op PHP gerelateerde cms als Wordpress etc. stemt niet tot vrolijkheid. Vooral plug_in code en ook verouderde kernelcode. Af te voeren jQuery bibliotheken. Soms kan het nog wat tegengegaan worden door instellen van Security Headers etc.
luntrus
Zit je met analytics big data en alle onderliggende tools inclusief het OS dan gebeurt er hetzelfde.

Kwestie van wat woordjes / technieken uitwisselen. Met een hoge correlatie kan er sprake zijn van een gedeelde toot cause.

Als je de besluitvormingsprocessen de werkwijzen (bedrijf, intermediar, ICT - strategie tactisch operationeel) doorloopt zie je dat dat gedeeld wordt. http://123management.nl/0/020_structuur/a232_structuur_03_informatie_management_9vlaks.html
Nog een stap verder.
Dat dit model gebruikt wordt heeft een reden. Mogelijk is dat het te grote gat tussen ICT als techniek en het bedrijfsdoel.
Dat ICT niet lekker ligt in verkoop/boekhouding geloof ik. De interessantere vraag hier op dit forum is hoeveel ict-ers bezig zijn met de bedrijfsdoelen te begrijpen en met die wat te doen.
29-04-2018, 08:28 door Krakatau - Bijgewerkt: 29-04-2018, 09:05
Het begint weer wat te verwateren in off-topic gezijspoor. Dus nog maar eens, in de herhaling, on-topic.

Door Krakatau:
Door Anoniem:
Door Anoniem: PHP is meer een bijeengeraapt zooitje, dan een programmeertaal aldus Jeff Atwood eens.
Het probleem is meer dat PHP programmeurs een bijeengeraapt zootje zijn.
Je kunt best goed programmeren in PHP maar helaas is "PHP voor dummies" het level waarop de meeste mensen
werken. Als je dan een groot project met vele contributors hebt dan weet je zeker dat er keer op keer problemen zijn.

Als er plugins ondersteund worden, hou dan maar helemaal op. Dan heb je het niet meer in de hand.

Nee, als er na alle kritiek iets duidelijk is, dan is het wel dat dit bij PHP niet alleen het probleem is. Om het vriendelijk en rustig te zeggen.

PHP is a 'grown' language rather than deliberately engineered, making writing insecure PHP applications far too easy and common. If you want to use PHP securely, then you should be aware of all its pitfalls.

https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

As a result, about 79% of all PHP websites run at the moment on a vulnerable PHP interpreter.

https://blog.ripstech.com/2017/security-flaws-in-the-php-core/

What you're seeing is not Photoshopped. This is an actual photo of a real world, honest to God double-clawed hammer. Such a thing exists. Isn't that amazing? And also, perhaps, a little disturbing?
...
Remember the immediate visceral reaction you had to the double-clawed hammer? That's exactly the reaction most sane programmers have to their first encounter with the web programming language PHP.

https://blog.codinghorror.com/the-php-singularity/
(met dank aan @luntrus)

PHP is the lone exception. Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can’t even point out any single damning thing, because the damage is so systemic.

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Door Anoniem: PHP is meer een bijeengeraapt zooitje, dan een programmeertaal aldus Jeff Atwood eens.

Ergo: liever geen op PHP gebaseerde architectuur gebruiken.

Zie dit dus liever niet: https://www.drupal.org/node/1880590

Krakatau hier zal het wel met mij eens zijn, anderen ook als ze nadenken over alle ellende van dien.

"PHP, weg ermee!".

luntrus

@luntrus Inderdaad!
29-04-2018, 09:37 door Anoniem
Weet nog uit de tijd van f.r.a.v.i.a en PHP hacker Laurent, dat PHP inherent onveilig was vol mijnenvelden voor beginners en weinig oog voor veiligheid. Ontwerp maar eens een weak PHP dictionnaire voor Intellitamper en zie de PHP sites "openvliegen".
luntrus
29-04-2018, 10:28 door Anoniem
alle argumenten/tekorten hierboven over PHP kun je ook min of meer stellen als je in assembly programmeert desalnietemin zijn er hele goede redenen soms om iets in assembly te doen.

zo zijn er ook plenty issues met java :

https://en.wikipedia.org/wiki/Criticism_of_Java

dus mennekes, stop eens een tool tot stokpaardje te verheffen :)

een programmeur die maar een programmeer taal beheerst is geen programmeur, dat is een beginner.
29-04-2018, 11:42 door Krakatau - Bijgewerkt: 29-04-2018, 11:43
Door Anoniem: alle argumenten/tekorten hierboven over PHP kun je ook min of meer stellen als je in assembly programmeert desalnietemin zijn er hele goede redenen soms om iets in assembly te doen.

zo zijn er ook plenty issues met java :

https://en.wikipedia.org/wiki/Criticism_of_Java

Leuk maar van een andere orde. Binnen de categorie professioneel gereedschap kan je kritiek hebben op Java (of C# of C++). Het blijven echter professionele gereedschappen. Dat kan je niet zeggen van PHP. Dat is voor eenvoudig thuisgebruik.

Door Anoniem: dus mennekes, stop eens een tool tot stokpaardje te verheffen :)

een programmeur die maar een programmeer taal beheerst is geen programmeur, dat is een beginner.

Gesproken als een ware scriptkiddie! Echter een vakman kent z'n gereedschappen! En kiest daaruit professioneel gereedschap. Daar valt PHP helaas niet onder.
29-04-2018, 12:09 door karma4
Door Krakatau:
...
Gesproken als een ware scriptkiddie! Echter een vakman kent z'n gereedschappen! En kiest daaruit professioneel gereedschap. Daar valt PHP helaas niet onder.
Waarmee je aangeeft dat jij niet in de positie zit voor die keuzes maar iets als beheerder opgelegd krijgt. Met het negatieve gedoe van anderen afbranden zul je geen verandering bereiken, integendeel.
Je enige kans zal zijn om te laten zien dat je het sneller goedkopen en beter kan.

Stel dat je wel zaken zou gaan beslissen en opleggen dan is mijn voorspelling dat het volledig vastloopt en er uiteindelijk alleen verliezers zullen zijn. Een voorspelling uit ervaring met waarnemingen.
29-04-2018, 12:09 door karma4
Door Krakatau:
...
Gesproken als een ware scriptkiddie! Echter een vakman kent z'n gereedschappen! En kiest daaruit professioneel gereedschap. Daar valt PHP helaas niet onder.
Waarmee je aangeeft dat jij niet in de positie zit voor die keuzes maar iets als beheerder opgelegd krijgt. Met het negatieve gedoe van anderen afbranden zul je geen verandering bereiken, integendeel.
Je enige kans zal zijn om te laten zien dat je het sneller goedkopen en beter kan.

Stel dat je wel zaken zou gaan beslissen en opleggen dan is mijn voorspelling dat het volledig vastloopt en er uiteindelijk alleen verliezers zullen zijn. Een voorspelling uit ervaring met waarnemingen.
29-04-2018, 13:01 door Krakatau - Bijgewerkt: 29-04-2018, 13:06
Door karma4:
Door Krakatau:
...
Gesproken als een ware scriptkiddie! Echter een vakman kent z'n gereedschappen! En kiest daaruit professioneel gereedschap. Daar valt PHP helaas niet onder.
Waarmee je aangeeft dat jij niet in de positie zit voor die keuzes maar iets als beheerder opgelegd krijgt.

Vertel eens! Hoe trek je die conclusie? Ik zie niet hoe je dat op basis van wat ik schreef zou kunnen doen. Doe je dat vaker, in het wilde weg conclusies trekken op basis van niet aanwezige feiten? Nogal dom dan. Maar dat past wel in het beeld dat ik van je heb:

- https://www.security.nl/posting/556525#posting556570
- https://www.security.nl/posting/556593#posting556693
- https://www.security.nl/posting/555153#posting555203

(een steeds populairder wordend lijstje, anderen gebruiken het ook al zag ik).

Door karma4: Met het negatieve gedoe van anderen afbranden zul je geen verandering bereiken, integendeel.
Je enige kans zal zijn om te laten zien dat je het sneller goedkopen en beter kan.

Niet dus want ik krijg niets opgelegd. En ik ben geen 'beheerder'.

Door karma4: Stel dat je wel zaken zou gaan beslissen en opleggen dan is mijn voorspelling dat het volledig vastloopt en er uiteindelijk alleen verliezers zullen zijn. Een voorspelling uit ervaring met waarnemingen.

Je eerder getrokken 'conclusie' dat ik een 'beheerder' zou zijn die niets kan beslissen of opleggen is onjuist. Moet ik nu nog ingaan op bovenstaande 'onzin gestapeld op onzin'? Naah...
29-04-2018, 13:16 door karma4 - Bijgewerkt: 29-04-2018, 13:17
Door Krakatau: ....
Je eerder getrokken 'conclusie' dat ik een 'beheerder' zou zijn die niets kan beslissen of opleggen is onjuist. Moet ik nu nog ingaan op bovenstaande 'onzin gestapeld op onzin'? Naah...
Jouw conclusies slaan nergens op. En je kunt het inhoudelijk niet aan om vervolgens op de man te gaan spelen.
Met linkjes naar voorgaande posts doe ik niets, het geeft aan dat je niets te zeggen hebt en geen inhoud hebt.
Met wat je loslaat over je situatie is een andere conclusie dan beheerder die niets te zeggen heeft niet mogelijk.
Het gedrag past daar uitstekend bij, vaker gezien en beleefd. Goed dank je voor de bevestiging van jouw capaciteit.
29-04-2018, 16:51 door Krakatau - Bijgewerkt: 29-04-2018, 17:22
Door karma4:
Door Krakatau: ....
Je eerder getrokken 'conclusie' dat ik een 'beheerder' zou zijn die niets kan beslissen of opleggen is onjuist. Moet ik nu nog ingaan op bovenstaande 'onzin gestapeld op onzin'? Naah...
Jouw conclusies slaan nergens op. En je kunt het inhoudelijk niet aan om vervolgens op de man te gaan spelen.
Met linkjes naar voorgaande posts doe ik niets, het geeft aan dat je niets te zeggen hebt en geen inhoud hebt.

Integendeel! Die linkjes zijn naar posts waar JIJ non-inhoudelijke onzin hebt verkondigd die je niet recht weet te zetten! Nee, natuurlijk 'doe je niets' met linkjes naar voorgaande posts. Dan kan je namelijk helemaal niet! Het enige wat jou dan resteert is die onzin te gaan bagatelliseren. Dat werkt echter niet. Onzin is namelijk onzin en iemand die steevast onzin verkondigt wordt al snel niet meer serieus genomen. Waarom neem ik eigenlijk nog de moeite om op jou te reageren? Je blijkt immers prima in staat om jezelf totaal belachelijk te maken met jouw inhoudsloze onzin posts. Jij schertsfiguur :-)

Door karma4: Met wat je loslaat over je situatie is een andere conclusie dan beheerder die niets te zeggen heeft niet mogelijk.

Niet? Leg dan eens stap voor stap uit hoe je op basis van wat ik hier loslaat over 'de situatie' - https://www.security.nl/posting/559943#posting560161 - tot die conclusie bent gekomen?

Door karma4: Het gedrag past daar uitstekend bij, vaker gezien en beleefd. Goed dank je voor de bevestiging van jouw capaciteit.

Jouw inschatting van mijn capaciteiten is net zo zwak en slaat de plank net zo totaal mis als de onzin die je in andere posts verkondigt. Zie het inmiddels bekende lijstje.
29-04-2018, 19:12 door Anoniem
" Waarmee je aangeeft dat jij niet in de positie zit voor die keuzes maar iets als beheerder opgelegd krijgt. Met het negatieve gedoe van anderen afbranden zul je geen verandering bereiken, integendeel. "

beste karma, neem dat advies vanjezelf nu eens zelf ook te harte als er iets over windows voorbij komt een keertje.
29-04-2018, 19:22 door Anoniem
Door Krakatau:
Door Anoniem: alle argumenten/tekorten hierboven over PHP kun je ook min of meer stellen als je in assembly programmeert desalnietemin zijn er hele goede redenen soms om iets in assembly te doen.

zo zijn er ook plenty issues met java :

https://en.wikipedia.org/wiki/Criticism_of_Java

Leuk maar van een andere orde. Binnen de categorie professioneel gereedschap kan je kritiek hebben op Java (of C# of C++). Het blijven echter professionele gereedschappen. Dat kan je niet zeggen van PHP. Dat is voor eenvoudig thuisgebruik.

Door Anoniem: dus mennekes, stop eens een tool tot stokpaardje te verheffen :)

een programmeur die maar een programmeer taal beheerst is geen programmeur, dat is een beginner.

Gesproken als een ware scriptkiddie! Echter een vakman kent z'n gereedschappen! En kiest daaruit professioneel gereedschap. Daar valt PHP helaas niet onder.

joh doe eens niet zo een karma-kronkel.

FB gebruikt PHP, volgens jou zijn dat dus amateurs die maar wat prutsen met inferieure tools.

hier een ander leuk lijstje :

https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites

zie je een beetje in waarom het een onzin conclusie van je is?
29-04-2018, 20:21 door Krakatau - Bijgewerkt: 29-04-2018, 20:23
Door Anoniem:
Door Krakatau:
Door Anoniem: alle argumenten/tekorten hierboven over PHP kun je ook min of meer stellen als je in assembly programmeert desalnietemin zijn er hele goede redenen soms om iets in assembly te doen.

zo zijn er ook plenty issues met java :

https://en.wikipedia.org/wiki/Criticism_of_Java

Leuk maar van een andere orde. Binnen de categorie professioneel gereedschap kan je kritiek hebben op Java (of C# of C++). Het blijven echter professionele gereedschappen. Dat kan je niet zeggen van PHP. Dat is voor eenvoudig thuisgebruik.

Door Anoniem: dus mennekes, stop eens een tool tot stokpaardje te verheffen :)

een programmeur die maar een programmeer taal beheerst is geen programmeur, dat is een beginner.

Gesproken als een ware scriptkiddie! Echter een vakman kent z'n gereedschappen! En kiest daaruit professioneel gereedschap. Daar valt PHP helaas niet onder.

joh doe eens niet zo een karma-kronkel.

FB gebruikt PHP, volgens jou zijn dat dus amateurs die maar wat prutsen met inferieure tools.

Historisch gegroeid ongetwijfeld. En moet je eens kijken wat ze hebben moeten doen om er een werkbare programmeertaal van te maken. Kan je dat nog wel PHP noemen? Met zo'n VM is het meer Java of C# aan het worden. Maar toegegeven, als je maar genoeg geld hebt om in te stoppen dan is het blijkbaar wel bruikbaar te maken.

https://en.m.wikipedia.org/wiki/HHVM

Door Anoniem: hier een ander leuk lijstje :

https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites

zie je een beetje in waarom het een onzin conclusie van je is?

Nou... Het is een leuk lijstje hoor, dat wel. De basis PHP zie ik door grote partijen niet gebruikt worden. Die gebruiken HipHop Virtual Machine (HHVM). Uitgezonderd WordPress misschien...
29-04-2018, 22:27 door Anoniem
Beste security dot nl posters in deze draad.

Tijdens een lange wandeling langs de wilde blauwe hyacinthen in het Belgische Hallerbos heden middag op de grens tussen het Vlaamse en Waalse land, liet ik het hele Drupal, Word Press, Magento veiligheidsverhaal nog eens goed op me inwerken en dus in het bijzonder de relatie tot PHP.

Dit om een bijdrage te kunnen leveren aan de discussie, waarmee we een handvat hebben tot deze algemene problemen. Hoe komen we verder en hoe coderen we inherent veiliger? Dat is dus onze vraag.

Check alles hieronder goed na op valide en oneigenlijke argumenten. Ik heb de wijsheid niet in pacht en leer graag, want zodoende groeit mijn kennis en het bijbehorende inzicht!

Als PHP nog enigszins gebruikt kan worden, dan is het samen met cheatsheets ernaast. Er is een Word Press Help Sheet, een Reference Sheet Basics, Smarti Cheat Sheet voor template ontwerpers, PHP Unit Cheat sheet en nog een achttal. andere cheatsheets.

PHP is echter heel vaak de blinde die de blinde leidt en vaak vallen daarna beiden in de gracht.
Voor beginners een valide punt.

Hoe schrijven we een absoluut kwetsbare applicatie?

Gebruik PHP niet voor "untrusted input". PHP code kan problematisch zijn als er exploits "in the wild" bestaan.
Maar dat geldt ook wederom voor alle ongeteste code.

PHP draait alleen als CGI, complete reinitialisatie, dus van een script na elke request.

Je weet niet wat voor SQL kwetsbaarheden er zijn en wat ze eventueerl uit kunnen richten.
XSS-DOM idem ditto.

Je moet het telkens handmatig gaan fixen.

De automatische conversie tussen strings & numbers is zo complex
dat het de inspanningen van de programmeur vaak niet loont om eraan te beginnen.

PHP is een interessant doelwit voor hackers.
Interne hacks voeren steeds weer tot fouten in de veiligheidsimplementaties.
Maar dit geldt voor alle complexe programma's. Oneigenlijk argument dus.

De lage instap en installeer Apache met mod_php, gooi de app in /var/www en
wacht op het daarop volgend wereldeinde.

Grondprobleem is niet de taal op zich maar de manier waarop het ontworpen is.
PHP heeft nooit het "classes"stadium gehaald.

Net als javascipt uit den beginne was het nog niet klaar voor op een Internet
en in een website omgeving gebruikt te worden. I

nfo credits gaan uit naar security dot stackexchange dot com
(diverse bijdragen over de inherente onveiligheid van PHP, ja of neen).

Kijk eens naar de mogelijke issues met een mogelijke op PHP gebaseerde Magento webshop site: https://www.magereport.com/scan/?s=https://www.robotshop.com/
Hier bij deze voorbeeldscan schijnt het bijzonder goed te zijn afgelopen.

Er is echter ruimte voor verbetering: https://retire.insecurity.today/#!/scan/2bf679730519bb3343a2d92b2f3d12f818b2213b9f33748af45a8a0a0e3e6e39

Even javascript hier aan de tand gevoeld
connect.facebook.net/US/fbevents.js
status: saved 39794 bytes 0f5781bbf62772f60515926378d453e071d1b598
info: [decodingLevel=0] found JavaScript
error: undefined variable fbq
error: undefined variable history
error: undefined function f.ensureModuleRegistered

,Echt we moeten meer met veiligheid op het netvlies en in het achterhoofd gaan werken, beste mensen.
Vele eindgebruikers zullen u allen hier dankbaar voor zijn.

m.vr.gr.

luntrus
30-04-2018, 08:43 door Anoniem
uit je HHVM link:

"HHVM brings many benefits in comparison with HPHPc, and one of them is almost complete support for the entire PHP language as defined by the official implementation of PHP version 5.4"


dus is het nu de gramatica van de taal waar je steeds over valt, of een of meerdere de implementaties daarvan? desalnietemin , er zijn dus plenty grote jonges die de PHP gramatica gebruiken al dan niet via HHVM en JIT technologie en je stelling is duidelijk een karma-conclusie-stokpaard-opmerking-om-te-negeren geweest.
30-04-2018, 12:49 door Krakatau - Bijgewerkt: 30-04-2018, 12:50
Door Anoniem: uit je HHVM link:

"HHVM brings many benefits in comparison with HPHPc, and one of them is almost complete support for the entire PHP language as defined by the official implementation of PHP version 5.4"

dus is het nu de gramatica van de taal waar je steeds over valt, of een of meerdere de implementaties daarvan? desalnietemin , er zijn dus plenty grote jonges die de PHP gramatica gebruiken al dan niet via HHVM en JIT technologie

Historisch gegroeid gebruik van PHP (grammatica) is iets anders dan optimaal. Ik kan me best voorstellen dat wanneer je een hele grote source code base hebt in PHP, dat je dan niet op een andere taal wil/kan overstappen. Hoe goed de argumenten ook zijn. Dat zal echter wel geld kosten, om continu alle pitfalls af te dekken (zie de PHP security cheatsheets die een andere poster hier noemt). Daar kies je dan voor. Bij de eerstvolgende grote redesign van de software kan je dan PHP uitfaseren en een echte programmeertaal gaan gebruiken.

Door Anoniem: en je stelling is duidelijk een karma-conclusie-stokpaard-opmerking-om-te-negeren geweest.

Wil je me s.v.p. niet met karma4 gaan vergelijken want dat trek ik echt niet ;-)
30-04-2018, 13:37 door Anoniem
Door Krakatau:
Door Anoniem: uit je HHVM link:

"HHVM brings many benefits in comparison with HPHPc, and one of them is almost complete support for the entire PHP language as defined by the official implementation of PHP version 5.4"

dus is het nu de gramatica van de taal waar je steeds over valt, of een of meerdere de implementaties daarvan? desalnietemin , er zijn dus plenty grote jonges die de PHP gramatica gebruiken al dan niet via HHVM en JIT technologie

Historisch gegroeid gebruik van PHP (grammatica) is iets anders dan optimaal. Ik kan me best voorstellen dat wanneer je een hele grote source code base hebt in PHP, dat je dan niet op een andere taal wil/kan overstappen. Hoe goed de argumenten ook zijn. Dat zal echter wel geld kosten, om continu alle pitfalls af te dekken (zie de PHP security cheatsheets die een andere poster hier noemt). Daar kies je dan voor. Bij de eerstvolgende grote redesign van de software kan je dan PHP uitfaseren en een echte programmeertaal gaan gebruiken.

Door Anoniem: en je stelling is duidelijk een karma-conclusie-stokpaard-opmerking-om-te-negeren geweest.

Wil je me s.v.p. niet met karma4 gaan vergelijken want dat trek ik echt niet ;-)


eerst laat je je erg ongenuanceedr en negatief uit over PHP, dan krijg je een lijstje van grote clubs die PHP doen, daarvan stel jij dat dat HHVM is en dus iets anders, maar ik citeer uit je referentie en vraag daarom nogmaals of het je om de gramatica van PHP gaat of de implementatie. wel gebruik je weer statements als 'PHP uitfaseren en een echte programmeertaal gaan gebruiken.' dat is erg vooringenomen, zeker als je voorbij gaat aan de referenties die ik je gegeven had en op de laatste vraag krijg ik niet eens een antwoord volgens mij.

ik blijf daarom de vergelijking met karma handhaven.
30-04-2018, 13:46 door Anoniem
@Krakatau & anderen in deze draad,

PHP als kapstok-taal lijkt me ook niet mijn eerste keuze, maar als basis om alert te worden op allerlei doorwerking van fouten is het misschien de manier om te leren hoe je het niet moet doen. "Bagger in = bagger uit". Lijkt me beter om met node.js e.d. te beginnen. Goed dat ik in 2004 van f.r.a.v.i.a. de beginselen van PHP en zwakke cgi heb geleerd en zelfs bij hem op z'n site hierover mocht publiceren.

Jammer dat deze reverse engineer van het eerste uur en latere searchlore guru zo snel is komen te overlijden. Hij valt te scharen in het rijtje van andere grote Italianen, zoals de man die aan de wieg van NoScript staat, Giorgio Maone.

Waar ik vooral aandacht voor wil vragen na duizenden en duizenden op Word Press, Drupal & Magento CMS gebaseerde sites te hebben gezien en "doorgespit", is het feit dat dat beginnende developers (en ik kom ze regelmatig tegen tijdens toetsen) zo weinig aangeleerd krijgen over veilig coderen en gangbare 'safeguarding' methoden naar zowel de taal als de code-omgeving toe.

"Schakel Windows 10 in op silent mode" roep ik dan nog, maar als je nog niet sec logisch kan denken over wat een volledige "array" is en je moet gaan zitten gokken, dan blijven we met aantallen kwetsbare websites zitten van 60 tot 80% voor de meest gangbare PHP gebaseerde "CMS varianten".

Het wordt de code en algoritme scharrelaars van de grote CDNs en Big Data schuivers als facebook etc. daardoor wel erg gemakkelijk gemaakt om de boel ten eigen voordele in de maling te kunnen nemen.

Nog te makkelijk weten ze door de gatenkaas te boren. Het grote publiek heeft het nakijken, maar niet security bewuste programmeurs en beheerders ook en wat al niet te denken van (politieke) handhavers. Ik zou het graag anders zien of gaan beleven, maar om wille van de smeer likt de kat de kandeleer en verandert er maar mondjesmaat iets fundamenteels.

Voorlopig is wat we hier doen "preaching to the choir" en vaak paarlen voor de zwijnen en vaak vechten tegen de bierkaai.

Als er dan ook nog arrogante "ik wil perse mijn gelijk halen" spelletjes worden gespeeld hier, wordt het helemaal dubieus en er nog steeds niet veiliger op. Ik wordt vaak weggezet als scan ridder, die nergens verstand van heeft en het eerste wat men doet is proberen iemands autoriteit onderuit te schoffelen. Wat dat aangaat is het wederzijdse respect vaak ver te zoeken. Kruis de degens op argumenten en niet door met een grote bek 'op de man' te spelen of spijkers op laag water te zoeken. Muggenzifters en netenkreten weten vaak het minst.

Nog iemand over het steeds meer jassen van server naar de steeds moeilijk te beveiligen client wellicht?

gegroet,

luntrus (cold reconnaissance 3rd party website analyticus en website foutenjager sinds 2006).
30-04-2018, 16:12 door Krakatau - Bijgewerkt: 30-04-2018, 16:40
Door Anoniem:
Door Krakatau:
Door Anoniem: uit je HHVM link:

"HHVM brings many benefits in comparison with HPHPc, and one of them is almost complete support for the entire PHP language as defined by the official implementation of PHP version 5.4"

dus is het nu de gramatica van de taal waar je steeds over valt, of een of meerdere de implementaties daarvan? desalnietemin , er zijn dus plenty grote jonges die de PHP gramatica gebruiken al dan niet via HHVM en JIT technologie

Historisch gegroeid gebruik van PHP (grammatica) is iets anders dan optimaal. Ik kan me best voorstellen dat wanneer je een hele grote source code base hebt in PHP, dat je dan niet op een andere taal wil/kan overstappen. Hoe goed de argumenten ook zijn. Dat zal echter wel geld kosten, om continu alle pitfalls af te dekken (zie de PHP security cheatsheets die een andere poster hier noemt). Daar kies je dan voor. Bij de eerstvolgende grote redesign van de software kan je dan PHP uitfaseren en een echte programmeertaal gaan gebruiken.

Door Anoniem: en je stelling is duidelijk een karma-conclusie-stokpaard-opmerking-om-te-negeren geweest.

Wil je me s.v.p. niet met karma4 gaan vergelijken want dat trek ik echt niet ;-)

eerst laat je je erg ongenuanceedr en negatief uit over PHP, dan krijg je een lijstje van grote clubs die PHP doen, daarvan stel jij dat dat HHVM is en dus iets anders, maar ik citeer uit je referentie en vraag daarom nogmaals of het je om de gramatica van PHP gaat of de implementatie. wel gebruik je weer statements als 'PHP uitfaseren en een echte programmeertaal gaan gebruiken.' dat is erg vooringenomen, zeker als je voorbij gaat aan de referenties die ik je gegeven had en op de laatste vraag krijg ik niet eens een antwoord volgens mij.

Natuurlijk is de grammatica van PHP een probleem! Daaronder vallen echter niet de functies uit de standard library, die met name het probleem zijn. En het ontbreken van meta-informatie in gecompileerde code, zodat refactoring van code niet betrouwbaar kan worden gedaan. Dat grote bedrijven vanuit een historisch gegroeid perspectief er toch voor kiezen om met PHP of derivaten (HHVM) te blijven werken, dat is toch niet zo moeilijk te vatten? Dat doet niets af aan dat het - zeker wanneer je met een nieuw project begint - uiterst onverstandig is om dat in PHP te doen. Daarvoor heb ik ondertussen toch genoeg onderbouwing - met referenties - gegeven?

Door Anoniem: ik blijf daarom de vergelijking met karma handhaven.

Lache :-)
30-04-2018, 19:19 door Anoniem
"Natuurlijk is de grammatica van PHP een probleem! Daaronder vallen echter niet de functies uit de standard library, die met name het probleem zijn. En het ontbreken van meta-informatie in gecompileerde code, zodat refactoring van code niet betrouwbaar kan worden gedaan. Dat grote bedrijven vanuit een historisch gegroeid perspectief er toch voor kiezen om met PHP of derivaten (HHVM) te blijven werken, dat is toch niet zo moeilijk te vatten? Dat doet niets af aan dat het - zeker wanneer je met een nieuw project begint - uiterst onverstandig is om dat in PHP te doen. Daarvoor heb ik ondertussen toch genoeg onderbouwing - met referenties - gegeven?"

dus de run time lib (implementatie) is je punt, niet de synthaxis want anders had je nooit het HHVM argument kunnen gebruiken dat de volledige PHP synthaxis ondersteund. met diezelfde logica kan iemand een ongefundeerde mening hebben over bijv java als die persoon een 'rottige' implementatie tegen komt. mijn argument om af en toe assembly te gebruiken als voorbeeld dat er situaties kunnen bestaan die jij niet kent waarbij PHP toch de betere keuze kan zijn staat dus mooi nog overeind. het sterk en negatief uitlaten van je over PHP alsof het geen fatsoenlijke programmeer taal is gaat dus voorbij aan wat zaken en daarom is je post nog steeds karma-esque van aard. een stokpaard dingetje van je dus.
30-04-2018, 22:30 door Anoniem
@ anoniem van 19:19

Daarom blijft het een kwestie van goed weten wat je aan het doen bent. Nog genoeg problemen, bijvoorbeeld met een Zimbra webmail service certificering op root, die in omgekeerde volgorde staat door een bijkomende 502 Bad Gateway ZCS upstream server in storing. PHP api-wrapper aanwezig. Storinggevoelige narigheid, vooral met een auto-exploiter in de buurt, die naar iets anders wijst, Luxemburg bij voorbeeld.

Dit alles tenminste als je niet precies weet wat je aan het doen bent. De complexiteit is aan sommigen echt niet besteed.
Maar je zult maar een halve dag niet bij je webmail kunnen, juist nu we daar steeds meer afhankelijk van zijn gemaakt.
Ik geef je de verzuchtingen online door. (Pfeee..........ewh) Niet te zuinig dus.

Dit mag mn met kritische structuren dus niet laten gebeuren. Zeker als je voor deze webmail diensten vooruit betaalt.

Nitwits horen dus niet aan de knoppen te zitten. Daar vermoed ik ook de insteek van de andere posters in dezen draad en "little old me". Karma4 vertel eens hoe zit dit op ninx? Was wat ik boven aanhaalde ten gevolge van het klaarzetten voor het sleepwet gebeuren van morgen?

luntrus
01-05-2018, 09:52 door Krakatau - Bijgewerkt: 01-05-2018, 10:48
Door Anoniem:
Door Krakatau:"Natuurlijk is de grammatica van PHP een probleem! Daaronder vallen echter niet de functies uit de standard library, die met name het probleem zijn. En het ontbreken van meta-informatie in gecompileerde code, zodat refactoring van code niet betrouwbaar kan worden gedaan. Dat grote bedrijven vanuit een historisch gegroeid perspectief er toch voor kiezen om met PHP of derivaten (HHVM) te blijven werken, dat is toch niet zo moeilijk te vatten? Dat doet niets af aan dat het - zeker wanneer je met een nieuw project begint - uiterst onverstandig is om dat in PHP te doen. Daarvoor heb ik ondertussen toch genoeg onderbouwing - met referenties - gegeven?"

dus de run time lib (implementatie) is je punt, niet de synthaxis want anders had je nooit het HHVM argument kunnen gebruiken dat de volledige PHP synthaxis ondersteund.

HHVM ondersteunt misschien de volledige PHP syntax maar dat maakt het nog geen professionele programmeertaal! Het blijft PHP, met al haar zwaktes. Dat sommige grote bedrijven vanuit historisch gegroeid perspectief ervoor kiezen om er toch mee te werken doet daar niets aan af. Met heel veel geld en moeite weten ze blijkbaar om de zwaktes van PHP heen te werken. Dat moet je niet willen wanneer je aan een nieuw project begint. Dan kies je voor een echte programmeertaal. Want jij kan wel denken dat je net als Facebook wel met PHP om kan gaan, dat is echter niet het geval. PHP gaat je gewoon de kop kosten want er zijn talloze subtiele en minder subtiele manieren waarop je de mist in kan gaan. Al dat gedoe heb je niet met een echte programmeertaal.

Door Anoniem: met diezelfde logica kan iemand een ongefundeerde mening hebben over bijv java als die persoon een 'rottige' implementatie tegen komt. mijn argument om af en toe assembly te gebruiken als voorbeeld dat er situaties kunnen bestaan die jij niet kent waarbij PHP toch de betere keuze kan zijn staat dus mooi nog overeind.

Nee want bij PHP is het de basis die totaal verrot is! Niet een enkele 'implementatie' Het is gewoon geen professioneel ontworpen programmeertaal. Het is organisch gegroeid, waarbij amateuristisch en knoeierig laag op laag is gestapeld. Heb je mijn referenties niet gelezen of gewoon niet begrepen?

Door Anoniem: het sterk en negatief uitlaten van je over PHP alsof het geen fatsoenlijke programmeer taal is gaat dus voorbij aan wat zaken en daarom is je post nog steeds karma-esque van aard. een stokpaard dingetje van je dus.

Mooi woord wel, karma-esque. Maar lees mijn referenties eens en probeer ze te begrijpen. Dan snap je ook waarop professionals zo negatief zijn over PHP. Hier heb je er nog eentje:

And four out of five apps written in PHP, Classic ASP, and ColdFusion failed at least one of the OWASP (Open Web Application Security Project) Top 10 benchmarks. Of the range of programming languages studied, .NET and Java fared the best.

Chris Wysopal, founder and CTO of Veracode, told Dark Reading: “When I see a breach, one of the things that sticks out in my head is ‘I’ll bet that was a PHP site.'”

https://thenewstack.io/php-7-boasts-doubled-performance-though-security-concerns-linger/

N.B.: ik heb zelf - vnl. backend software - geprogrammeerd in PHP. En dan heb ik het niet over een pluginnetje voor een CMS of iets dergelijks. In vergelijking met bv. Java EE is het simpelweg speelgoed. Niet meer en niet minder. Je moet in PHP zoveel meer moeite doen om valkuilen te vermijden, om dingen heen te werken, langlopende taken op de server uit te voeren.
01-05-2018, 10:43 door Anoniem
Facebook HHVM met het cached PHP veiligheidsprobleem goedpraten. Hou toch op stelletje veiligheidsondergravers met een verborgen agenda.
luntrus
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.