WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws
1–10 of 54 posts
Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws
#2Ironic
Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws
#3SQL 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?
Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws
#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 flaws in Hide My WP version 6.2.4, released on October 26.
Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws
#5WP can't fix this entire class of vulnerabilities properly or it won't be Wordpress any more. It is unfortunate that Wordpress is one of the worse options for making websites today (not WP itself, but any theme or plugin can easily be coded to have SQLi), yet it is the most popular.
Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws
#6SQL 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.
Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws
#7Not 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.
Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws
#8SQL 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.
With regards to the database. Not UNIX root.
Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws
#9SQL 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.
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.
Re: WordPress security plugin Hide My WP addresses SQL injection, deactivation flaws
#10SQL 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 is row level security. But that usually means many db users or sometimes usergroups are supported.
https://www.postgresql.org/docs/current/ddl-rowsecurity.html