15 Jul 10 Another PHP tip

While it’s all well and good to spend considerable time securing your PHP applications, there is something else that you can do, or rather not do. As a PHP programmer, I see people do one alarming thing: they download and install PHP applications from questionable sources.

While there are a lot of honourable programmers who offer their scripts for free, there are plenty of hackers who enjoy deploying applications that cause harm to others. I discussed this earlier, but it bears repeating: trust your source. Know your source.
(more…)

Tags: php programmer, php programmer resume, safety, script, security, trust

12 Apr 10 Timing operations in PHP with microtime

Within PHP, we have a function called microtime(bool $float).

When microtime() is called without any arguments it will return a string in the form of “microseconds seconds” i.e. “0.70801200 1271088014″ which is the number of seconds and microseconds since the Unix Epoch (0:00:00 January 1, 1970 GMT).

When microtime is called with a ’1′, i.e. <? echo microtime(1); ?> it will return the number of microseconds alone which is going to be more useful for what we want to achieve, i.e. “1271088173.97″

So using this, we can now write a script that we want to time, for example:

<?php
echo “Script Starting\n”;
$start_time = microtime(1);
for ($i = 0; $i < 10000000; $i++)
{
//perform some calculation
$n = $i%247;
}
$end_time = microtime(1);
echo “Our script took: ” . ($end_time – $start_time) . ” to run\n”;
?>

The output of this script is:

adam@vm1-webserver01:/tmp$ php ./t.php
Script Starting
Our script took: 1.45122814178 to run

Now you can add a $start_time = microtime(1); to the top of any script that you have, and a $end_time = microtime(1); echo $end_time-$start_time; to the end of any script that you have to time it, or alternatively just time certain portions to see where you can optimize things.

Tags: epoch, microtime, PHP, script

27 Oct 09 BASH Script – Blank Out CC Details

Edit: I should have pointed out originally, as I have now received feedback on this. This is NOT the best or optimal way of performing this task. I was trying to illustrate as many shell scripting principles as possible in terms of ‘if’, ‘for’, counters, etc, and how such a one liner has been put together. Perhaps I should have thought of a better way of illustrating such principles, but nevertheless, here it is!

Here’s a quick one liner, can’t think why anyone would ever have any use for it, but maybe the principle itself could be of use to someone! This will take a file containing listings of 16 digit numbers, i.e. 1234123412341234 and replace it with XXXXXXXXXXXX1234

Duly spaced and indented:

Would love anyone to comment with variations.

Tags: bash, echo, grep, script, tr

18 Sep 09 Web Application Security Consultant Methodology

I wanted to share some thoughts on my general methodology when approaching web application pen testing. Depending on size, scope of work, complexity and a number of factors, there are two separate angles, usually both or a hybrid of both that I will take.

The first angle has to be the network security itself, all the way down the the physical security. As a penetration tester, I’ll test the web, database, storage and any other related networked devices inside and out. Port scanning their interfaces, spoofing IPs and MACs, asking myself questions such as “Does the database accept direct connections from any IP? Does Apache keep too many spare threads waiting?” We need to work our way from bottom to top of the OSI Model, a lot of which can be done using nc (Netcat) and a combination of scripts, as well as nmap.

Secondly, as the security consultant, I would then test the application itself and dependant or otherwise related applications. Crawl the site and it’s file hierarchy using wget or similar, and then run automated test tools, such as burpsuite, acunetix and a combination of curl/wget and shell scripts before manually drilling down into anything suspicious. Unfortunately for the user, the majority of web applications are insecure. A web crawl using a recursive wget, followed by some blind SQL injection checks will more often than not turn up the opportunity for SQL injection. Once this is done, the next query is how far I can go with the SQL injection. Do I have root access now to the database? Does the database user have unnecessary permissions? I should be able to SELECT and possible INSERT/UPDATE data. It’s unlikely that I should be able to actually alter, or even drop the database from the web user. Having table update priviledge on all tables is just as good as being able to drop the database itself though in terms of potential damage. This combination of security issues could lead to even further damage once the initial compromise has been made.

The next question is how far to proceed once an opportunity has been identified. Is demonstrating an opportunity for SQL injection sufficient, or does the opportunity need to be exploited? Once done, does data actually need reading or writing to the database or code changed? This generally depends on the scope of the work and purpose/setting of the systems under test. More will be discussed on this in later articles.

Once complete, I will generally report and rate the issues found from 1 to 5. 1 being informational, 2 being low severity, 3 being medium severity, 4 being high severity and 5 being critical severity. The database user having additional priviledges may fall into categories 3 or 4. An outdated but currently secure version of the webserver running may fall in to category 1, whilst an SQL injection opportunity will for sure fall in to category 5.

Scope depending, I can either discuss the issues and advise on strategies to resolve, or alternatively provide the report ready for the Client to pass on to his own IT consultant.

Tags: acunetix, axunetix, burpsuite, curl, netcat, nmap, osi model, pen test, penetration test, script, Security Consultant, shell, sql, sql injection, web application, wget

09 Sep 09 Shell Return Codes – Ping Monitoring

BASH – The Bourne Again Shell amongst most if not all other shells allows each application to exit with a return code. Some shells and environments have limits on what range this integer can fall into. Something between 0 and 255 inclusive is always a safe bet. In BASH, the variable $? is populated with the return code of the last command to return control back to the shell. It is important to preserve the return code immediately after the application exits that we want to monitor, as subsequent commands will overwrite the variable. The ping tool returns 0 on success:

Now of course there are easier ways of achieving the above task, although I’ve laid out the script in this way hoping that the way I have laid it out illustrates capturing the code and preserving it beyond the ‘if’ that follows which would have overwritten it. Just as further illustration, calling ping invalid followed directly by echo $? shows a return code of ’2′ – obviously the return code for such a failure. Calling echo $? again immediately after shows a return code of ’0′ as the return code of ping was overwritten by the return code of the first echo statement. Bash builtins return codes to the shell as any other application would.

Tags: bash, host, monitor, ping, return code, script, shell, shell script, uptime, variable