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

51–54 of 54 posts

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

#51

Post by simondotau »

asddubs wrote: post #30
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.

I have no problem placing "if" or "switch" statements within the SQL in order to enable/disable various components of the query. The risk is when you're bringing in anything other than local constants.

In the rare instances where I do this, I'm analysing the full scope of potential valid variables. I then make local copies of the variables which have been pummelled with the narrowest possible regular expression, e.g.

  slightly_safer = unsafe.replace(/[^0-9A-Za-z]/gi, '')
Stripping away all punctuation eliminates most forms of SQLi.

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

#52

Post by rmbyrro »

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?

Weird - or, oddly, not surprising - that no one seems to be using these tools

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

#53

Post by asddubs »

simondotau wrote: post #51
asddubs wrote: post #30

Earlier quoted context omitted.

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.

I have no problem placing "if" or "switch" statements within the SQL in order to enable/disable various components of the query. The risk is when you're bringing in anything other than local constants. In the rare instances where I do this, I'm analysing the full scope of potential valid variables. I then make local copies of the variables which have been pummelled with the narrowest possible regular expression, e.g.…

for mysql at least, if you're dealing with table names you can just do a backtick escape, where you wrap the table/column name in backticks and escape any backticks within it with two backticks. That's usually my go-to in situations like this, in addition to a whitelist. anything else you can usually parameterize

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

#54

Post by simondotau »

asddubs wrote: post #53
simondotau wrote: post #51

Earlier quoted context omitted.

I have no problem placing "if" or "switch" statements within the SQL in order to enable/disable various components of the query. The risk is when you're bringing in anything other than local constants. In the rare instances where I do this, I'm analysing the full scope of potential valid variables. I then make local copies of the variables which have been pummelled with the narrowest possible regular expression, e.g.…

for mysql at least, if you're dealing with table names you can just do a backtick escape, where you wrap the table/column name in backticks and escape any backticks within it with two backticks. That's usually my go-to in situations like this, in addition to a whitelist. anything else you can usually parameterize

Relying on escape sequences is a serious footgun risk as there's always going to be some weird scenario that can be exploited against you, such as alternative ways to escape backticks that quietly gets enabled when some unexpected incident forces you to rebuild your MySQL Server instance.

When you're bringing in strings from outside, there's no such thing as being too paranoid. White-listing of permitted characters is the only safe approach. (And if you think your whitelist might ever need contain any kind of quote-mark, backtick or backslash, then you're wrong. Your table/identifier names are stupid and must change.)

Post reply on HN