Live data from Hacker News

WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws

portswigger.net

11–20 of 54 posts

Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws

#11

SQL injection draws attention to the fact that almost all web applications run as root, in regards to the most important asset: the data. It’s odd that this hasn’t got more attention. It should be easier to write backends that tie data access more closely to user credentials without the backend trying to enforce that itself. Is there anything out there that makes this easy to do?

There isn't, at least not really, since webapps are designed as full-service kiosks: all of the data management, user management and access control are supposed to be handled from the same console. If you want the database to enforce access controls, then every user must exist as a separate entity in the database, which is good, but then the webapp also needs the permissions to manage user accounts in the database, which is bad for security, and the webapp can no longer use connection pooling, which is bad for performance.

There are tricks you can use, such as implementing row-level security and tying it to some concept of end user identity, but even ignoring that ORM's don't understand or support RLS and developers therefore won't use it: it's still the same problem of letting the fox guard the henhouse. The webapp is the single control point for both user access and user administration (including self-service account creation and password reset), so whatever solution you come up with, the webapp will need to have super-user access to do that, and therefore if the webapp is compromised, your data-level access controls can be compromised too.

So, in order to even begin thinking about securing your data, the webapp should probably be split into multiple reduced-access microservices that handle different aspects of the webapp function. As long as we're talking about a single monolithic backend, any attempt at scope mitigation can (and likely will) be defeated.

Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws

#13

SQL injection draws attention to the fact that almost all web applications run as root, in regards to the most important asset: the data. It’s odd that this hasn’t got more attention. It should be easier to write backends that tie data access more closely to user credentials without the backend trying to enforce that itself. Is there anything out there that makes this easy to do?

If your database supports session wide environment variables you can attach user/group/permissions object to the session and have your queries/functions/procedures check that.

If your database supports writable views (e.g. via triggers) you can build parametric views.

Both are not plug-and-play modules in your framework and requires actual DBA, though.

Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws

#14
This is one of those types of things that shouldn’t happen anymore, but does.

I’m pretty sure that WordPress now has their own low-level version of PDO Prepared Statements. Also, they have a lot of even higher-level DB abstractions. I can’t think of any reason to directly access the DB from a plugin or theme.

Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws

#15
post #12

I'm not familiar with WP under the hood. Am I being naive or is it feasible to write a routine that scans plug-ins source code looking for insecure query argument handling?

semgrep has php support, so it should be possible, at least with respect to the “basic” APIs. If a plugin wraps the raw sql apis I don’t think semgrep can “inline” the information, so you’d have to reach for the taint tracking but that’s way more complicated than just check rules.

Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws

#16

This is one of those types of things that shouldn’t happen anymore, but does. I’m pretty sure that WordPress now has their own low-level version of PDO Prepared Statements. Also, they have a lot of even higher-level DB abstractions. I can’t think of any reason to directly access the DB from a plugin or theme.

> I can’t think of any reason to directly access the DB from a plugin or theme.

Because it's PHP and it's easy.

Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws

#17
post #11

SQL injection draws attention to the fact that almost all web applications run as root, in regards to the most important asset: the data. It’s odd that this hasn’t got more attention. It should be easier to write backends that tie data access more closely to user credentials without the backend trying to enforce that itself. Is there anything out there that makes this easy to do?

There isn't, at least not really, since webapps are designed as full-service kiosks: all of the data management, user management and access control are supposed to be handled from the same console. If you want the database to enforce access controls, then every user must exist as a separate entity in the database, which is good, but then the webapp also needs the permissions to manage user accounts in the database, w…

It's not that we don't know how to build things securely, it's just that we routinely ignore even basic principles of security 'cause it's easier. Virtually every webapp violates complete mediation and so it's just unreasonable to expect security. Similarly, most developers don't care for security and even less about principles and system design. Again, it's unreasonable to expect secure outcomes from that.

Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws

#18
post #16

This is one of those types of things that shouldn’t happen anymore, but does. I’m pretty sure that WordPress now has their own low-level version of PDO Prepared Statements. Also, they have a lot of even higher-level DB abstractions. I can’t think of any reason to directly access the DB from a plugin or theme.

> I can’t think of any reason to directly access the DB from a plugin or theme. Because it's PHP and it's easy.

Too true. It’s not PHP’s fault, though. The same type of argument is applied to C++.

We keep developing “nerf-world” languages, designed to protect ourselves from ourselves, and most fall down before they get a chance to even get going; mostly because they constrain, without empowering. I remember moving to Pascal, after using Assembly and Machine Code. It was very frustrating for me. Pascal was one of the earliest “safe” languages.

The problem is that we can’t build houses, using PlaySkool “Li’l Builder” toolsets.

Also, the WP Codex is really disorganized. It’s difficult to find anything in it, and that is deadly.

Geeks like to design clever architectures, but we hate to document them.

Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws

#19

SQL injection draws attention to the fact that almost all web applications run as root, in regards to the most important asset: the data. It’s odd that this hasn’t got more attention. It should be easier to write backends that tie data access more closely to user credentials without the backend trying to enforce that itself. Is there anything out there that makes this easy to do?

I always wondered, how do they exfiltrate the data? The website isn’t designed to display any schema. Do they save it as file from the SQL server? Can’t that be locked down? The attacker would still be able to delete but at least not extract.

Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws

#20
post #7

Not surprising to me. I work at a small company, focused on industrial automation. It can be very expensive and time-consuming to automate things, so our internal processes are ironically manual. Customers don't pay us to automate our internal processes, so that never gets done.

But it doesn’t cost more to use a parametrised query. That’s dev incompetence not cost pressure.
Post reply on HN