WP-Motorn Ett Bra webbhotell? Att Ge Felaktiga Uppgifter om WordPress Plugin Sårbarheter till Sina Kunder

När det gäller att få information om säkerhetsfrågor i WordPress plugins, utvecklare av plugins är inte alltid den bästa källan. Som är fallet med en ihållande cross-site scripting (XSS) upptäcktes av Federico Scalco som var i plugin Caldera Formulär. Samtidigt som hävdades av upptäckaren av sårbarhet, utvecklare av plugin, och alla andra datakällor av sårbarheter i WordPress plugins vi är medvetna om, att rättats i version 1.6.0 av plugin, det var faktiskt inte, så testa de hävdade sårbarhet skulle ha visat några av dem (enkel test som skulle vara något som vi kommer gå in på i ett annat inlägg). Om du använder våra tjänster du skulle ha varit korrekt meddelas att det inte hade varit fast.

Det har nu rättats i version 1.6.1.1. Här vad det utvecklare skrev om att:

den Här versionen är en extra fix för CVE-2018-7747 . Jag blev uppmärksammad tidigare i dag att det var ett kvarstående problem som inte kommer att få fast. Säkerhetsproblem som vi avslöjade för två veckor sedan kallas en lagrad XSS sårbarhet. I enklare termer så betyder det att det var ett sätt att använda Caldera Former för att lagra en del JavaScript som kan utlösas att köra senare.

I Calderan Former 1.6.0 jag använde en funktion som tar bort alla JavaScript på produktionen som tidigare utnyttjas. Som hindrade den lagrade köra JavaScript. Eftersom utnyttja en lagrad XSS sårbarheter är två steg-processer — butik och sedan hämta senare — den här uppdateringen förhindrar problemet från att utnyttjas i framtiden.

Caldera Former 1.6.1.1 ger samma skydd i en mer plats och förhindrar att de beteenden som visades för mig idag.

Även om vi inte nämnde det för någon anledning, vi var de som anmält utvecklare av det som inte är fasta. Verkligheten är att 1.6.0 inte hade tagit bort “alla JavaScript på produktionen som tidigare utnyttjas” och den plats som påstods vara visat att dem var en del av den ursprungliga rådgivande i frågan.

trots att vi är som inte nämns i att de gjorde länk till en av datakällor, WPScan Vulnerability Database, som felaktigt hävdade att problemet hade varit fast innan. Det är inte den enda gången som utvecklare av plugin har nyligen befordrad som datakälla, trots att utvecklaren nu att veta att de ger felaktiga uppgifter.

Den andra exempel vi stötte på dök upp i vår övervakning av wordpress.org Support Forum för att hålla koll på sårbarheter i WordPress plugins. Svar till någon som ber om ett meddelande från WPScan Sårbarhet Databas om sårbarheten utvecklaren skrev här:

Ja, det finns korrigeringar i 1.6.0. Jag arbetade med de utvecklare som finns och ansvar ut frågor. En del av denna process är att registrera det i och med databasen. Att handlingar frågan.

ännu viktigare, det utlöser varningar som plugins behöver för att vara uppdaterade på bra värdar. Jag fick ett meddelande från WPEngine om min egen sida. Det är det bästa system som finns tillgängliga för oss för att få ordet ut om vuldrabilites som inte är allvarliga.

Vi tror inte att ett bra webbhotell skulle vara att sprida WPScan s felaktiga uppgifter utan att åtminstone ha en disclaimer att de uppgifter som har allvarliga kvalitetsproblem, vilket kan ha varit en påminnelse till utvecklaren att de inte skall vara att främja den. Genom att främja datakällor som inte ansvariga med sina uppgifter, utvecklare är faktiskt skadar användare av deras plugins, eftersom om vi inte existerade då sårbarheten skulle troligen ha varit kvar i plugin för överskådlig framtid. Om fler människor kände till sanningen om vad olika datakällor förutsatt att det sannolikt skulle innebära fler kunder till våra tjänster, vilket skulle innebära att vi skulle kunna göra ännu mer för att förbättra säkerheten i WordPress plugins (och därför WordPress i allmänhet), som redan är förmodligen mer än alla andra säkerhetsföretag ut det.

Något annat vi märkt att det verkar värt att notera att det gäller att förbättra säkerheten för plugins var något som nämns i inlägget tillkännage lanseringen av version 1.6.0 av plugin:

för att se till att fixa detta förhindrar att dessa potentiella XSS-sårbarheter, och också att vi inte återinföra den sårbarhet, vi har skapat nya automatiserade tester. Dessa tester, som är i ett eget git-arkivet, kommer att köras på framtida releaser och vi kommer att lägga till ytterligare säkerhetskontroller i framtiden.

Klart de automatiserade testerna egentligen inte åstadkomma det. Bara i allmänhet, och vår erfarenhet är att automatiserad testning är användbar som ytterligare ett verktyg för kunniga proffs vid kontroll över säkerheten för ett WordPress-plugin eller andra program, men de har vissa allvarliga brister och sina förmågor är ofta överskattas.