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

21–30 of 54 posts

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

#21

Post by pdimitar »

formerly_proven wrote: post #17
tremon wrote: post #11

Earlier quoted context omitted.

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.

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.

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

#22

Post by virgilp »

Newrelic synthetic check cannot be used to verify that newrelic site is functional(their synthetic checks use Chrome 72, their site understandably doesn't support such old browsers)

There's a saying here that the shoemaker's children walk barefoot. I think this might not be an isolated phenomenon

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

#23

Post by bflesch »

cm2187 wrote: post #19
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?

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 measured from the attacker side because the SQL query will block the HTTP response.

This way, without "seeing" a result, the attacker is able to return data.

[1] https://en.m.wikipedia.org/wiki/File:ASCII-Table-wide.svg

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

#24

Post by raxxorrax »

Hendrikto wrote: post #6
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?

> 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.

I think you need root permissions to start a network service on port 80 on Windows. There is a security risk here which was addressed in a fairly recent Chrome release that local addresses need a respective CORS rule. At least I believe so.

Disadvantage with the Windows behavior is that a webservice running on said port has elevated permissions and if you surf the web with the same machine, a script inserted into a site could launch attacks against it. Of course the site itself could be malicious, in that case the CORS rule wouldn't do much.

Of course you are correct, running directly on port 80 might just be a bad idea, but for development purposes I might do that.

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

#25

Post by Vogtinator »

raxxorrax wrote: post #24
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.

I think you need root permissions to start a network service on port 80 on Windows. There is a security risk here which was addressed in a fairly recent Chrome release that local addresses need a respective CORS rule. At least I believe so. Disadvantage with the Windows behavior is that a webservice running on said port has elevated permissions and if you surf the web with the same machine, a script inserted into a s…

Ports What usually happens is that the process only has the necessary capability for a brief period to open the port and drops it immediately before processing any requests.

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

#26

Post by simondotau »

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 concatenation is happening all the time. This is a very old language which will look embarrassingly janky compared to any of the new hotness in vogue on Hacker News. But even in CFML I can trivially guarantee zero SQLi by parameterising all variables.

Query parameters. They're a thing. If you don't know how your favourite programming language has implemented them, learn it. Use them.

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

#27

Post by iso1631 »

Hendrikto wrote: post #6
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?

> 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.

It was poorly phrased, but the OP meant that web apps usually have full unrestricted access to the database. Clearly that's not entirely true (your webapp likely doesn't need truncate, or the ability to add/change stored procedures, or the schema) but it's broadly there. Your database is effectively chmod o+r

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

#28

Post by [deleted] »

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…

[deleted]

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

#29

Post by [deleted] »

Hendrikto wrote: post #4

> “The function hmwp_get_user_ip tries to retrieve the IP address from multiple headers, including IP address headers which can be spoofed by the user such as X-Forwarded-For,” reads a blog post published by Jong yesterday (November 24). ”By supplying a malicious payload in one of these IP address headers, it will be directly inserted into the SQL query which makes SQL injection possible.” > wpWave [adressed] both fl…

[deleted]

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

#30

Post by asddubs »

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…

I agree of course, and in the case of the article you're absolutely right, although more generally there are edge cases where parameterization doesn't work, like giving choice of which row to order by. Naturally in such cases you should be operating on a whitelist of options and not pass the user input to the query, but the point is that some situations do still have to be accounted for.
Post reply on HN