Check for `.sql` files that could be easily publicly-exposed

[danielbachhuber]

For instance, {DB_NAME}.sql in the web root or wp-content directory can be easily guessed.

However, we shouldn't flag SQL files generated by backup plugins and similar that either live in obscured directories (some hash appended) or are protected by .htaccess files.

[Sidsector9]

@danielbachhuber I want to work on this but I am not that familiar with protecting directories using .htaccess. Can you point me to a resource/example where I can get a fair idea about this?

[danielbachhuber]

I want to work on this but I am not that familiar with protecting directories using .htaccess. Can you point me to a resource/example where I can get a fair idea about this?

See https://stackoverflow.com/questions/9282124/deny-direct-access-to-a-folder-and-file-by-htaccess

But, now that I've shared this, I don't think it's a hard requirement for the pull request. Directories may be blocked in some other way (e.g. Nginx) so it would be impossible to test them all.

[schlessera]

Would it make sense to add a --probe flag (which might be enabled by default) that tries to access the files through an external request?

[austinginder]

On unix based systems, one way to solve would be a simple file permission check. If a .sql file is set open 777 (or anything with world permission not set to 0) you can recommend or automatically assigning 600 permissions.