no love for .php5? + Information Leakage check behaviour

Just noticed there's no checks in WebInspect that involve the .php5 extension. Many hosting services, where PHP4 still exists and is utilised by way of the .php extension, require that .php5 extension be used in order to utilise PHP5.

Just ran a little test (using the default "standard" policy, restricted to directory and subdirectories only, path truncation disabled) on a directory containing the following:

tests/index.php5   (the target...aka: tests/ )

tests/debug.php

tests/debug.php3

tests/debug.php5

tests/debug/index.php5   (aka: tests/debug/ )

 (note: the files simply display their corresponding filename and contain no links)

However WebInspect only found:

tests/

tests/debug/

 

So why didn't Check #1376 find 'debug.php'?

and why didn't Check #1377 find 'debug.php3'?

What's confusing me is that those files are found by those checks when path truncation is enabled...

Thanks for bringing this to our attention. We are constantly fine tuning our vulnerabilities database and assessment engines to identify vulnerabilities in a wide array of languages, platforms, and applications. Specific vulnerabilities in those files, such as SQL Injection, would be flagged via a different methodology when found during a crawl. However, the specific checks you mentioned should also have registered. I suspect the Smart Assessment didn't have enough information to determine that PHP was running--is it possible you disabled Smart Assessment rather than Path Truncation (the settings are in the same spot)?

*** interesting to see Checks #1376 and #1377 have been removed with today's Smart Update...?!...well, despite this, I'm still going to talk about them :) ***

Definitely had 'Enable Path Truncation' unchecked (and checked for the subsequent test) - enabling it meant the difference between a 15minute scan and a 2.5hour scan in this case. I double checked, prior to initial post, that with Path Truncation disabled, debug.php and debug.php3 are not detected.

The target URL served the following response:

HTTP/1.1 200 OK
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
Transfer-Encoding: chunked
Date: Thu, 10 Apr 2008 03:01:57 GMT
Content-Type: text/html
Server: Apache
X-Powered-By: PHP/5.1.4
Keep-Alive: timeout=10, max=10

filename: index.php5

So unless Smart Assessment is ignoring the X-Powered-By header and not recognising .php5 as PHP then it should have detected the presence of PHP, right? Looks like that isn't the case, as only when I added a hyperlink to a .php file within the target file's response did Check #10184 'PHP Version Information Disclosure' get run...which poses the problem, how does PHP get recognised by Smart Assessment if, say, mod_rewrite is being used to hide all .php file extensions?

The similar checks to find debug.txt, debug.asp, debug.html are picking those files up when Path Truncation is disabled and there are no hyperlinks in any responses to those files...so were the debug.php and debug.php3 checks bugged?

FYI: those two checks were replaced by a new check, #10461.

My testing was unable to duplicate the Path Truncation difference you noted--so I suspect something is different in your test environment compared to mine. You can enable "Traffic Monitor Logging" to determine what is being tested, if you like. If this is an issue for you, please contact support so they can look into it directly with you.

In my tests of the index.php5 situation, it is indeed recognized properly by Smart Assessment. I urge you to perform another Smart Update (to ensure you have the very latest checks), and run the scan again. If it does not correctly identify PHP, I recommend contacting support so more direct action can be taken.

-Chris

w00t, she's working a lot better today!

Smart Scan has detected PHP from the X-Powered-By header and once PHP is detected those debug files are being looked for and found (debug.php, debug.php3), except for debug.php5.

...however still not picking up PHP when there's no X-Powered-By header and only reference to a .php5 file (e.g. <a href="index.php5">index.php5</a>). Note: I did not reference an existent .php5 file, so ultimately no PHP file was served and no X-Powered-By=PHP/XXXX header was served. I can see reasons why this is so, but also potential problems due to it (such as failure to run any PHP checks against an entirely PHP system that's well disguised).

 

So is it fair to say WI runs ASP checks regardless of whether ASP has been detected or not, but will only run PHP checks if PHP is detected?