mboost-dp1

Shutterstock

Kritisk sikkerhedsfejl i populært WordPress-plugin sætter 200.000 websteder i fare

- Via The Hacker News -

Et populært WordPress-plugin, Ultimate Member, er blevet ramt af en kritisk sikkerhedsfejl, der gør op mod 200.000 websteder sårbare over for angreb.

Fejlen tillader uautoriserede angribere at oprette nye brugerkonti med administrative rettigheder, hvilket giver dem fuld kontrol over de berørte websteder.

Fejlen skyldes en utilstrækkelig bloklistelogik, der ændrer brugermetaværdien til administrator.

Selvom der er blevet udsendt delvise rettelser, er de ikke tilstrækkelige til at lukke sikkerhedshullet, og angribere har fundet måder at omgå dem på.

Brugere af Ultimate Member rådes derfor til at deaktivere pluginnet og gennemgå alle brugerkonti på administratorniveau for at sikre, at der ikke er blevet tilføjet uautoriserede konti.

Pluginnets udviklere har frigivet en ny version (2.6.7) for at afhjælpe fejlen og planlægger yderligere sikkerhedsforanstaltninger, herunder en funktion til at nulstille adgangskoder for alle brugere.





Gå til bund
Gravatar #1 - larsp
10. jul. 2023 04:26
Wordpress er et mareridt at vedligeholde. Hvis man ikke opdaterer siden konstant, er der stor risiko for at blive hacket. Hvis man opdaterer, er der risiko for breakage pga. plugins der holder op med at virke og ændringer i API der ødelægger customiseringer.

Jeg vil sige at Wordpress grundlæggende er en uheldig arkitektur. Det er fjollet at lade en hovedsageligt statisk sider blive dynamisk genereret af en spaghettisuppe af database, plugins og scripting sprog.

Næh, statisk generet HTML med javascript til alt det dynamiske, er en langt bedre løsning. Der er slet ingen, eller en langt, langt mindre angrebsflade på den måde.
Gravatar #2 - arne_v
10. jul. 2023 13:43
larsp (1) skrev:

Wordpress er et mareridt at vedligeholde. Hvis man ikke opdaterer siden konstant, er der stor risiko for at blive hacket. Hvis man opdaterer, er der risiko for breakage pga. plugins der holder op med at virke og ændringer i API der ødelægger customiseringer.


Baseret på overskrifter så virker det som en korrekt beskrivelse af virkeligheden.

larsp (1) skrev:

Jeg vil sige at Wordpress grundlæggende er en uheldig arkitektur. Det er fjollet at lade en hovedsageligt statisk sider blive dynamisk genereret af en spaghettisuppe af database, plugins og scripting sprog.

Næh, statisk generet HTML med javascript til alt det dynamiske, er en langt bedre løsning. Der er slet ingen, eller en langt, langt mindre angrebsflade på den måde.


Jeg ved ikke om beskrivelsen af WP som værende overvejende statisk er dækkende for WP brug.

For dem som installerer WP på deres web hotel for at publisere deres hjemme side med billeder af deres nuttede katte: ja.

Men SaaS blog?

Social media (som f.eks. newz.dk!)?

Ecommerce web site?
Gravatar #3 - arne_v
10. jul. 2023 13:56
#1 og #2

Hele ideen med at bygge en web applikation op omkring et CMS kan godt virke lidt sær.

Og der er en meget tæt integration. En WP applikation er faktisk mere en WP applikation end en PHP applikation som bruger WP.

Men det er ikke unikt for WP.

Java JCR løsninger (Adobe Experience Manager, Alfresco, Magnolia, Jahia etc.) og visse .NET løsninger (SiteCore, Umbraco etc.) er lidt af det samme.

Man søger ikke en generel Java web developer eller en generel ASP.NET developer til disse men en AEM developer eller en SiteCore developer til disse jobs.
Gravatar #4 - arne_v
10. jul. 2023 15:03
#1 #2 #3

Men vi har naturligvis også problemet med PHP "koderne".

"koder" : mit web hotel opdaterede fra PHP 5 til 7 og nu virker min kode ikke
"udvikler" : du bruger mysql extension ikke mysqli/PDO extension for at tilgå din database
"koder" : det har virket fint indtil nu
"udvikler" : mysql extension har været deprecated i mange år - du skulle have konverteret koden til mysqli eller PDO for lang tid siden
"koder" : ja ja - hvad skal jeg rette?

og:

"koder" : mit web hotel opdaterede fra PHP 7 til 8 og nu giver min kode en masse fejl
"udvikler" : du bruger variable som ikke er sat
"koder" : det har virket fint indtil nu
"udvikler" : koden har altid været dårlig - PHP har bare hævet severity fra notice til warning
"koder" : ja ja - hvad skal jeg rette?
Gravatar #5 - Claus Jørgensen
10. jul. 2023 17:05
#4

Det er et fundamentalt problem i industrien at udviklere ikke opdatere deres kode til den sidste udgave af sproget/kompileren løbende.

C og C++ udviklerer er rigtig slemme til det.
Gravatar #6 - arne_v
10. jul. 2023 17:20
#5

Siger du at der er noget galt med C89 og C++98?

:-) :-) :-)
Gravatar #7 - arne_v
10. jul. 2023 17:26
#5

Min pointe var dog mere at visse sprog har en del ret håbløse "kodere" fordi de er "nemme".

PHP har mange.

Ada, C++ og Scala har ikke så mange.

De to eksempler var jo ikke god kode dengang PHP ikke gav fejl på den. PHP opdateringen bragte bare den dårlige kode frem i lyset.
Gravatar #8 - Claus Jørgensen
10. jul. 2023 18:08
#7

Jeg har set rigtig meget håbløst C++ kode hos Microsoft (og i Google's open source projekter)

Der er bare ti millioner gange mere PHP kode end C++ kode, så du ser mere af det.
Gravatar #9 - arne_v
10. jul. 2023 23:36
#8

De fleste undersøgelser synes nu at vise at C++ og PHP er ca. lige store.

My hypotese er stadig:

niveau 1 : god Ada/C++/Scala
niveau 2 : ok Ada/C++/Scala, god Java/C#/C
niveau 3 : dårlig Ada/C++/Scala, ok Java/C#/C, god PHP
niveau 4 : dårlig Java/C#/C, ok PHP
niveau 5 : dårlig PHP

Gravatar #10 - Claus Jørgensen
11. jul. 2023 07:54
#9

Scala er en moderne udgave af Perl, koden er write-only. Scala udviklere synes altid at skrive ny kode fra bunden da de ikke kan rette i deres eksisterede kode, det er ihvertfald min erfaring (på professionelt niveau)
Gravatar #11 - larsp
11. jul. 2023 08:48
Claus Jørgensen (5) skrev:
#4

Det er et fundamentalt problem i industrien at udviklere ikke opdatere deres kode til den sidste udgave af sproget/kompileren løbende.

C og C++ udviklerer er rigtig slemme til det.

Jeg vil kalde mig en begynder i C++ og har kun prøvet kræfter med sproget et par gange, men jeg opdagede med det samme alle udfordringerne ved korrekt lifecycle management af objekter, sværhedsgraden i at lave korrekte copy og move constructors, rule of 5 osv. C++ er et urimeligt svært sprog med alt for mange muligheder for at lave fejl.

Jeg mindes at de nyere versioner af C++ indførte klare forbedringer i denne sammenhæng der gav mulighed for at lave korrekt og optimal kode mere enkelt, og i så fald, JA, for Guds skyld, opdater kode til at køre med nyeste C++ version.

C derimod.... Det er slet ikke den samme situation. Jeg vil faktisk anbefale at køre med en god gammel C89 standard, for det er ikke inkompatibiliteten værd at rode med de nyeste features. Det springende punkt i C er om udvikleren overhovedet bruger sproget korrekt specielt mht. encapsulation så alle lokale variable i et modul f.eks. er static. Ja, om udvikleren overhovedet har disciplin med C og H filer. Det er skræmmende ofte jeg har set total spaghetti i C, og her er versionen af C compileren et akademisk spørgsmål til sammenligning.
Gravatar #12 - larsp
11. jul. 2023 10:56
arne_v (2) skrev:
Jeg ved ikke om beskrivelsen af WP som værende overvejende statisk er dækkende for WP brug.

For dem som installerer WP på deres web hotel for at publisere deres hjemme side med billeder af deres nuttede katte: ja.

Men SaaS blog?

Social media (som f.eks. newz.dk!)?

Ecommerce web site?

Jeg tænkte mere på de mange landing pages, portfolioer, præsentationssider for virksomheder og den slags der er lavet i WP, og som nemt kunne være statisk hmtl.

Newz er vel en dynamisk side. Men i princippet kunne man vel godt lave en sådan side med en smule statisk html plus javascript der trækker alle nyhederne og kommentarerne. Det ville også åbne op for alternative måder at interagere med materialet, f.eks. apps. Nok ikke noget reklamebagmændene vil gå ind for :)

Det gør nærmest ondt at læse #4. Jeg vil gøre alt for ikke at bygge eller bruge LAMP web apps igen. PHP's "smarte" idé med kode og html vævet sammen har ført til megen lidelse.
Gravatar #13 - Claus Jørgensen
11. jul. 2023 12:06
larsp (11) skrev:
Jeg mindes at de nyere versioner af C++ indførte klare forbedringer i denne sammenhæng der gav mulighed for at lave korrekt og optimal kode mere enkelt, og i så fald, JA, for Guds skyld, opdater kode til at køre med nyeste C++ version.
Præcis.

Der er seriøst ingen grund til at bruge en C++ udgave uden smart pointers. Folk brugte jo alligevel boost eller hjemmelavede macro's til det samme før det blev standard.

Og C++17 har endelig fået rigtig MapReduce funktionalitet, hvilket gør koden så uendelig meget nemmere at læse / vedligeholde
Gravatar #14 - arne_v
11. jul. 2023 13:18
Claus Jørgensen (10) skrev:
#9

Scala er en moderne udgave af Perl, koden er write-only. Scala udviklere synes altid at skrive ny kode fra bunden da de ikke kan rette i deres eksisterede kode, det er ihvertfald min erfaring (på professionelt niveau)


Nogle sprog er bare komplicerede.

Ada 95 er også slem (Ada 83 er nogenlunde).

Nogen gange har jeg indtryk af at Scala udviklerne har en målsætning om at alt input skal være syntaktisk validt - de skal bare have fundet den ønskede semantik.

Og visse ting er efter min mening en katastrofe. Scala 3's ide med både at understøtte traditionelle {} blokke og Python lignende indrykningsblokke er håbløs.



Gravatar #15 - arne_v
11. jul. 2023 16:12
#C++ smart pointere

De er vel en god ide. Men det er vel en ide der er nødvendig p.g.a. kompleksisteten i sproget.


#include <iostream>
#include <memory>

using namespace std;

class X
{
private:
int v;
public:
X(int v) { this->v = v; cout << "construct " << v << endl; }
virtual ~X() { cout << "destruct " << v << endl; }
void hi() { cout << "hi " << v << endl; }
};

int main()
{
X o1(1);
X *o2 = new X(2);
unique_ptr<X> o3(new X(3));
o1.hi();
o2->hi();
o3->hi();
delete o2;
return 0;
}


3 måder at gøre næsten det samme på er ikke elegant.
Gravatar #16 - arne_v
11. jul. 2023 16:23
larsp (11) skrev:

C derimod.... Det er slet ikke den samme situation. Jeg vil faktisk anbefale at køre med en god gammel C89 standard, for det er ikke inkompatibiliteten værd at rode med de nyeste features.


Man kan ikke altid regne med at man har adgang til C11.

Men man har vel stort set altid adgang til C99 idag.

Jeg bruger dog heller ikke selv ret meget af det nye i C99.

Imidlertid er jeg de senere år kommet til den konklusion at der er en ny feature i C99 som jeg burde begynde at bruge konsekvent i.s.f. min traditionelle C89 stil.

Jeg burde stoppe med at bruge short int, int, long int og long long int - og skifte til int16_t, int32_t og int64_t.

Det undgår så mange problemer når man skifter fra en platform til en anden platform hvor de gamle int typer skifter implementation.

Og risikoen for at skule arbejde på en platform der ikke er 8/16/32/64 bit orienteret er minimal idag.

I meget gamle dage havde man computere med 36 bit integers og 60 bit integers. Men idag er alt 8/16/32/64 bit.

Gravatar #17 - larsp
12. jul. 2023 04:58
#16 Okay, jeg trækker mit udsagn tilbage, C99 med stdint.h, C++ style comments og f.eks. inline funktioner er klart forbedringer der er værd at tage med, og som jeg selv har brugt enormt meget. stdint.h definitionerne er specielt vigtige når man programmerer til microcontrollere der kan være 8 eller 16-bit native. Vil man have en 32-bit int, skal man altså bede om det på de platforme.
Gravatar #18 - arne_v
12. jul. 2023 15:04
larsp (17) skrev:

C++ style comments


Det er jo ikke noget som virkeligt betyder noget. Men //<EOL> er simpelthen mere bekvemt end /* */.

Tager man de historiske briller på og kigger fra 10000 fod så vil jeg sige at:
* 1960 sprogene var linie orienterede
* 1970 sprogene var statement orienterede
* 1980+ sprogene har fundet ud af at det bedste er statement orienteret kode og linie orienterede kommentarer

larsp (17) skrev:

stdint.h definitionerne er specielt vigtige når man programmerer til microcontrollere der kan være 8 eller 16-bit native. Vil man have en 32-bit int, skal man altså bede om det på de platforme.


Det er ikke kun embedded verden.

Det er også et problem med servere.

Nogen gange har man bare brug for at bestemme hvor meget data fylder.

Og det kan godt undre at C var så lang tid om at komme med en løsning.

Fortran (ikke standard men de gængse VAX extensions) har haft INTEGER*2, INTEGER*4 og INTEGER*8 siden 70'erne (OK - INTEGER*8 dukkede først op senere men ...).

I Pascal/Modula/Ada verdenen har man altid kunnet bruge 0..65535 eller -32768..32767 etc. når man ville have en helt bestemt integer (man skulle så også sikre sig at data var packed men ...).

Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login