Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

portswigger.net

Post reply on HN
Print view View original

31–40 of 54 posts

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

#31

Post by konha »

tremon wrote: post #11
angrygoat wrote: post #3

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…

There are some easy wins most applications could use but don‘t most of the time. Like having sensible permissions for your app-db-user. Running migrations in a separate process? No need to have permission to do schema changes. Events are only written to the db and not queried/viewed from the app itself? Grant only INSERT rights to the table etc.

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

#32

Post by withinboredom »

rmbyrro wrote: 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?

There’s a couple of excellent static analysis tools (phpstan, psalm) that can catch this kind of stuff. I’m 99% sure that psalm’s security suite would catch this.

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

#33

Post by willcipriano »

tremon wrote: post #11
angrygoat wrote: post #3

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…

I have experimented with a design that only allows the application to access a set of stored procedures via it's SQL user.

It seems to work, if you write complicated enough stored procedures you can enforce things like each entry must be created by a logged in user or whatever. Then the application is limited to interactions it's supposed to have, so it can't drop a audit table or something. I even did login via a stored procedure, confirming the hashed password matched and generating a bearer token that future stored procedures require to function.

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

#34

Post by vntok »

eliaspro wrote: post #9
Hendrikto wrote: post #6

Earlier quoted context omitted.

> almost all web applications run as root That‘s largely a configuration problem. They don‘t have to run as root, most of the time.

Should there ever be a web application that needs to run as root, it should be rewritten. All logic requiring root privileges should be moved into a separate system service with a minimal attack surface to which the web application delegates those special tasks.

You misunderstood the grandparent's comment and replied to a confused parent. The application does not need to run as root, however even when it runs as a normal user, it generally has full read/write access to the application database. Which is a problem that is not easily solvable.

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

#35

Post by mmaunder »

This plugin has a low install count for WordPress at around 26K. It’s a commercial plugin as opposed to one of the plugins in the WP repo which helps explain the low install count.

Most of the plugins that WP researchers look at are in the official repo with higher install counts, so it’s nice to see stuff like this get some code coverage among researchers.

Envato should really invest in their own automated and human vulnerability research. I think there’s probably a lot of badness out there among the commercial plugins but in many cases researchers have to buy the plugin to take a look.

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

#36

Post by Ginden »

bflesch wrote: post #23
cm2187 wrote: post #19

Earlier quoted context omitted.

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.

If you're able to inject SQL, and the return value of the SQL query is not directly displayed to the user, you may use a timing-based side channel to exfiltrate data. E.g. in order to exfiltrate the string "Test123" you would go character-by-character, starting with the first character "T". For each ASCII character you would wait 10ms, as "T" is ASCII #84 [1] you'd sleep() for 84*10=840ms. This sleep() can be measure…

We're there any actual timings attacks executed like this? I'm talking about stack "attacker => internet => reverse-proxy => app => database", not extracting data over LAN from exposed app.

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

#37

Post by Ciantic »

simondotau wrote: post #26

This is ridiculous. SQLi is a dumb problem and any development environment worth using should make it trivial to avoid. All you have to do is never allow SQL queries to be formed using string concatenation. Or if you do, make sure you're excruciatingly strict about it. I run a large-ish web application written in ColdFusion (more precisely, CFML running on the open source Lucee ) which is a language where string conc…

In WordPress the string concatenation in SQL is normal, even on the very first example:

    $results = $wpdb->get_results( "SELECT * FROM {$wpdb->prefix}options WHERE option_id = 1", OBJECT );
This is because the database tables aren't static, so one must add prefix to each table from a variable. It's horrible, it would have been far better if there was magic string like %PREFIX% to avoid that.

[1]: https://developer.wordpress.org/reference/classes/wpdb/#usin...

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

#38

Post by guiriduro »

pdimitar wrote: post #21
formerly_proven wrote: post #17

Earlier quoted context omitted.

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.

It's probably more charitable to say "most devs are not given time and effort bandwidth to care about security". Trust me I'd love to plug more holes before first production deployment but management (and my CTO) would never approve a time/energy budget for it.

In the current market, I hope it won't sound too disingenuous to suggest you look to work with management that does. You'll be happier, and the market signal of enough people doing it will improve conditions for everyone.

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

#40

Post by pdimitar »

guiriduro wrote: post #38
pdimitar wrote: post #21

Earlier quoted context omitted.

It's probably more charitable to say "most devs are not given time and effort bandwidth to care about security". Trust me I'd love to plug more holes before first production deployment but management (and my CTO) would never approve a time/energy budget for it.

In the current market, I hope it won't sound too disingenuous to suggest you look to work with management that does. You'll be happier, and the market signal of enough people doing it will improve conditions for everyone.

I don't disagree in principle but there are many other factors that increase my job happiness:

- We have deadlines but they are not strict and very rarely somebody is going to even ping you outside work hours. People there want some discipline but they don't micromanage.

- The atmosphere is 95% of the time super chill.

- There are no egos flying around (not more than usual anyway; I scheduled a meeting to explain some coding style practices that should be painfully obvious but hey, trying not to judge here).

- Technical excellence is appreciated by a very technical and careful CTO -- but is indeed often sidelined in favor of deadlines and business-enabling work. However, I have already successfully fought him and the CEO off on 2-3 technical excellence tasks by demonstrating they'll reduce future slowdowns. Doable but requires some brawling in meetings.

- Pay is one of the biggest in EU (although it's like 1.5x - 2.0x less the than the US one).

---

> and the market signal of enough people doing it will improve conditions for everyone.

I keep hearing this and I want it to be true but for 20 years of career I've never seen it, not once. Nowadays I no longer believe it. Everywhere I worked (I am mostly a contractor so it has been a very colorful career) the business will stick to their idea of "we can always hire somebody else" with persistence that you'd be jealous of -- I don't know if it's an illusion or not but trust me, it's VERY persistent. That alone weakens the point you brought up because employers simply don't believe it and often times go out of their way to look for those other mythical people -- and I've been told in several occasions that the business closed doors before they managed to repair their clusterf_ck of an app. That's how persistent they are in their thinking process that everyone is expendable.

Post reply on HN