Full-Disclosure Wins Again

twistedmoney99 writes "The full-disclosure debate is a polarizing one. However, no one can argue that disclosing a vulnerability publicly often results in a patch — and InformIT just proved it again. In March, Seth Fogie found numerous bugs in EZPhotoSales and reported it to the vendor, but nothing was done. In August the problem was posted to Bugtraq, which pointed to a descriptive article outlining numerous bugs in the software — and guess what happens? Several days later a patch appears. Coincidence? Probably not considering the vendor stated "..I'm not sure we could fix it all anyway without a rewrite." Looks like they could fix it, but just needed a little full-disclosure motivation."

Comments

Require login, forbid any subdirectory access.

[Spy der Mann]

I saw the vulnerability page. They don't have access restriction to subdirectories.

Here's how I've solved this problem:

1) Modify the htaccess (or even better, the httpd.conf) files, so that ANY access to any of the subdirectories of the main app is forbidden. The only exceptions are: a) submodule directories, whose php files do a login check, or b) common images (i.e. logos) /CSS/XSLT/javascript dirs.

2) The only way to view your files is through the web application's PHP file lister and downloader. This should be child's play for anyone with PHP knowledge: PHP has the fpassthru function, or if you're memory-savvy, use standard fopen. Make sure the lister doesn't accept directories above the ones you want to list, and for the files use the basename() function to strip them from subdirectories.

3) Any file in the PHP application MUST include() your security file (which checks if the user has logged in and redirects them to the login page otherwise). For publicly-available pages, add an anonymous user by default.

4) For log in (if not for the whole app), require https.

4a) If you can't implement https, use a salt-based login, with SHA-256 or at least MD5 for the password encryption.

5) Put the client's IP in the session variables, so that any access to the session from a different IP gets redirected to the login page (with a different session id, of course).

6) After log in, regenerate the session id.

7) Put ALL the session variables in the SESSION array, don't use cookies for ANYTHING ELSE.

I consider these measures to be the minimum standard for web applications. It shocks me that commonly used apps still fail to implement them properly.