I encourage people to google how to run phpMyAdmin, MySQL Workbench, or Sequel Pro locally, and use port forwarding over SSH. It's super simple.<p>Here is a command that forwards all traffic to localhost:3306 across the ssh tunnel to example.com:3306 (the mysql default port).<p><pre><code> ssh user@example.com -L 3306:localhost:3306
</code></pre>
I would never run a DB admin application on the live server because it's just one more piece that might open a security hole.
> A lack of filtering on user CSV output that could allow
an attacker to run arbitrary code on an administrator's
computer.<p>> Improper cookie invalidation that could allow an
attacker to unset internal global variables.<p>Those don't count as serious issues? Props to them for making the report public though.
I really hate the idea of having a web interface to my database anywhere, no matter how secure they say it is. Social engineering (over direct "hacking") lends itself to circumventing technical security.<p>No matter their technical security (Although I'm super happy they test phpmyadmin!), I still wouldn't trust it on my servers.<p>Granted you can lock phpmyadmin down via ip restriction, vpn, etc - that's definitely good, but, if you can forgive a bit of generalization, those measure tend to be above people's head or too restrictive for those using phpmyadmin.<p>If we do connect to a database using a GUI (usually an app instead of phpmyadmin), however, my preference is through an SSH tunnel. This lets us connect securely (over SSH), and still allow MySQL to not be globally accessible from the outside world - meaning, you can still using MySQL's built-in network security features (bind-address and username hosts, along with firewall restrictions) to lock down MySQL.
Stupid question, how does a security audit work? Do the consultants just read through the code? Do they try to find security bug like they do on bug bounty programs?
I wish NCC Group had been given more time, since phpMyAdmin is nigh-ubiquitous in legacy PHP apps.<p>For example:<p><a href="https://github.com/phpmyadmin/phpmyadmin/blob/4cd8ab8a957a2324b4e218acc048642b9a6d2a23/libraries/session.inc.php" rel="nofollow">https://github.com/phpmyadmin/phpmyadmin/blob/4cd8ab8a957a23...</a><p>Despite setting several security-related session configuration values, they don't touch the cookie entropy fields, which means a potential session fixation vulnerability.<p>This might not be a concern for most users: typically your distro ships a php.ini configured to read at least 16 bytes from /dev/urandom. But not always! Many projects set cookie.entropy_length and cookie.entropy_source just to be sure.
Is there much sense in auditing things that are usually used by the admin and are by design exposing a lot of control of the server? Sure it must not be exposed to an outsider, but if auth is done right, it doesn't matter how far the insider can get... IMO
"I'm not sure, what the guys did during the audit of phpMyAdmin, but it took me 3 minutes to find a persistent XSS in the latest version."<p><a href="https://twitter.com/totally_unknown/status/742753323468640262" rel="nofollow">https://twitter.com/totally_unknown/status/74275332346864026...</a>
I encourage everyone to use MySQL Workbench over SSH. For whatever reason people seem to not understand the concept of SSH and the inherent security it provides. But, once you explain to folks how to use it effectively it really is a good balance of security and usability.
> Software Freedom Conservancy congratulates its phpMyAdmin project on succesfuly completing completing a thorough<p>repetition of "completing" in first line.
And in the PDF, the auditors complain that they didn't have enough time to even fully analyze the impact of the vulnerabilities found.<p>I wouldn't read too much into it.