Adminer was voorheen phpmyadmin. Ze hebben de naam al aangepast om niet meer met dat hobbytaaltje geassocieerd te worden. Dat is helaas niet genoeg want het is nog steeds een in PHP geschreven tool. En dan weet je het wel, nietwaar?

"hobbytaaltje", alle programmeertalen zijn hobbytaaltjes, dat heeft verder niets met het artikel te maken.
Lekken komen in iedere programmeertaal voor, het is afhankelijk van de programmeur.

Zou er misschien ook mee te maken kunnen hebben, dat Adminer veel meer ondersteuning heeft voor andere databases? en phpmyadmin niet echt meer een juiste naam voor het product kan zijn?

Dus? Mooie universe programmeertaal. Wordt best veel gebruik op internet mocht je dat nog niet door hebben. Oa Wikipedia is er in geschreven.

Nee eigenlijk niet. Uit eindelijk hangt het van de programmeur af, hoe de kwaliteit van de code is.

@Tha Cleaner,

Wat een misvatting dat er geen verschillen zouden bestaan in de syntax van een bepaalde taal.
Is babel niet beter als plain javascipt voor specifieke toepassingen.
Daarnaast telt ook de interactie met de omgeving.
Denk aan de specifieke DOM-XSS ellende met bijvoorbeeld bootstrap.js en min.js etc.

Ook het voortduren van deze kwestbaarheden, nadat het ontwerpersteam het doortrok naar de volgende versie 3.0.4
Zie: https://snyk.io/vuln/npm:bootstrap:20180529 -

Gecompromitteerde websites kunnen vaak gelinkt worden met kwaadaardig script & het kan reeds fout gaan bij niet juist toepassen van installatiescripts.
Voorbeeldje af te voeren bibliotheek -> http://turkeytoday.org/media/jui/js/jquery.min.js?939b0ef64cfbe0ecf88c0a66e2818945
jQuery versions with known weaknesses
Bug 9521 - $("#<img src=x onerror=...>")
Bug 11290 - $("element[attribute='<img src=x onerror=...>'")
jQuery issue 2432 - 3rd party $.get() auto executes if content type is text/javascript
jQuery issue 11974 - parseHTML executes inline scripts like event handlers (uit de dagen van pre-HTML javascript).

Bij gepatchte code en niet toegevoegde extra hardening door middel van extra security maatregelen,
moet het sein veilig altijd nog weer getoetst worden.
Daar doen mindere en beter coderende developers helaas niets aan af en toe.

Brendan Eich bijvoorbeeld heeft zelf toegegeven, wat persistente ad-tracking van grote Big Tech Data Miners allemaal al voor ellende t.a.v. JavaScript heeft gebracht. Niet iedereen is er van op de hoogte dat zelfs het pre-loaden van webpagina's niet volgens de regels gebeurt, maar om Google chrome beter af te schilderen tegenover andere browsers.

Tot het moment dat zulk soort zaken openbaar worden aangekaart, gaan men ermee door.
Men past zich steeds aan als een kameleon. Nu gaan de pagina's pas te zien zijn als ze geheel geladen zijn.
Niet hoog tijd om het eens gezamenlijk structureel en fundamenteel aan de tand te voelen,
en dan "call a spade a spade". Waarom gebeurt dat dan maar zo mondjesmaat.

luntrus

Tijd om je Magento 1 of 2 CMS hier te testen: https://www.magereport.com/
Aanvaller moeten eerst een kwetsbare "open" adminer.php zien te vinden.
Fluitje van een cent via een shodannetje etc.

Opnieuw php, nu rond lekkende wachtwoorden. Het houdt maar niet op.

# sockpupet

PHP een hobby taaltje noemen is wel zeer een belediging voor velen.
Het is een prima taal om code zoals een website in te schrijven.
PHP 7.4 zal zelfs Java onder druk zetten (nee, niet javascript).
JavaScript was ook als een hobby taaltje begonnen door een enkele persoon, wat nu uitgegroeid is tot een volwaardige taal, zie NodeJS wat veel sprongen gemaakt heeft.

Zelf ben ik een voorstander voor PHP, Python (PyPy vanwege doei doei GIL of Cython) en C++.
Voor de rest, Java is een draak van een programmeer omgeving, veel resources nodig wat veelvuldig vaak niet nodig is.

Anyway, Symfony/Laravel is zeer populair de laatste tijd onder web and API programmeurs, dus ik zie het probleem niet.

phpMyAdmin nooit meer gebruikt sinds ik via MySQL command line alles kan doen.
Daarnaast, werkt HeidiSQL ook prima, via een VPN connecten naar de server, en de rest firewallen, klaar...

Hoi, Power2All

Maar met het blootleggen van kwetsbaarheden op een website CMS moet je wel blijvend doorspitten.

Vergelijk de algemene scan hier https://retire.insecurity.today/#!/scan/b2730c739adb8993201689359cdf96726cabc4186695df06b2bfc6221a3494d7
met de scan voor jquery.min.js/JSTag_1[c8fd][b28e] ,die we aanvankelijk niet hebben meegenomen.

Vervolgens blijkt die ook kwetsbaar, zie:
https://retire.insecurity.today/#!/scan/7187586fc2d44df7e5693019bd9efadbcd8530630d21e8eec7986cfba644e704

Vooral php-gebaseerd CMS (Magento, Word Press, Joomla) in de handen van degenen, die code-security niet voldoende op het netvlies hebben, alsmede het toepassen van een verhoogde beveiligingsgraad door het toepassen van zogeheten "best policies" vaak achterwege laten.

Dan hebben we het nog niet eens gehad in het bovenstaande geval over de DOM-XSS sources & sinks in de gebruikte script en bibliotheken, respectievelijk voor de onderhavige 41 sources en 17 sinks. Die leveren stuk voor stuk natuurlijk niet allemaal een toepasbare exploit/bug op, maar desalniettemin. Ik zie er te weinig oog voor en ik zie het ,vooral bij amateurs, teveel ellende opleveren.

In hoeverre php-code op zich inherent onveilig is blijft natuurlijk onderwerp van discussie. Af te voeren PHP code vormt altijd een risico, maar soms zit je met verplicht backporten. Met het voortdurend moeten checken van de code op bijvoorbeeld eendie ergens achterwege is gebleven, heeft onze vriend Krakatau wel een punt. Alhoewel zijn algemene kwalificering populariserend blijft in mijn ogen. Maar waar blijft, dat php-gerelateerde CMS in handen van hobbyisten heel veel ellende aan kan richten, net zoals gratis websoftware bij een cloud-abonnement bijvoorbeeld.

#sockpuppet

phpAdminer zou het in dat geval heten. Ik denk dat ze twee vliegen in een klap hebben geslagen en meteen hebben onderschoffeld dat het tooltje in PHP is geschreven.


Een 'mooie universe programmeertaal'? Weet je eigenlijk wel wat je schrijft? Natuurlijk wordt PHP veel gebruikt want het is goedkoop. De resulterende technical debt van al dat PHP-gebruik is voor ons allemaal een groot probleem.


Die misvatting is wijdverbreid. De programmeur heeft natuurlijk invloed, echter als je het echt wilt verklooien moet je de verkeerde programmeertaal gebruiken. Of erger nog, een taaltje dat helemaal niet is bedoeld voor serieus werk in professionele toepassingen. Omdat het goedkoop is en omdat jij de technical debt toch niet zelf hoeft op te lossen.


Ik denk dat je 'polariserend' bedoelt. Want ik wil zeker niet PHP populariseren. Voor de rest ben ik het met je eens. #sockpuppet ;-)