PHP - 13

iBlog - Ilia Alshanetsky

Quicksearch

Calendar

Syndicate This Blog

Comments

Thursday, September 15. 2005

PHP|Works Performance Talk Slides Posted by Ilia Alshanetsky in PHP, Talks at 15:48

Comments (0)
Trackbacks (3)

PHP|Works Performance Talk Slides

The slides from PHP|Works performance talk are now up, they are available in either PDF or PowerPoint form.

Thursday, September 15. 2005

PHP Security Slides Online Posted by Ilia Alshanetsky in PHP, Talks at 12:07

Comments (2)
Trackbacks (3)

PHP Security Slides Online

Slides for the PHP Security talk at PHP|Works are now up. You can download them in either PowerPoint or PDF form.

More to come shortly

Wednesday, September 14. 2005

lchash 0.9.1 released Posted by Ilia Alshanetsky in PHP at 18:08

Comments (4)
Trackbacks (0)

lchash is a little PHP extension that you can find at http://pecl.php.net/package/lchash which provides means of accessing and using native hash tables found in libC. The interface is really simple involving just 4 functions:

lchash_create() - initialize a new hash table
lchash_destroy() - destroy a hash table
lchash_insert() - insert key/value pair into the hash
lchash_find() - retrieve a values based on key

By using this mechanism you can create a very fast and effecient memory-based data store for a script's duration.

Tuesday, September 6. 2005

PHP Guide to Security is out! Posted by Ilia Alshanetsky in PHP at 10:23

Comments (9)
Trackbacks (3)

PHP Guide to Security is out!

About five months ago, during yet another flood of phpBB2 exploits Marco Tabini approached me with an idea of writing a security book for PHP. The idea was to provide a guide for people who want to make their applications safer as well as help them understand the possible consequences of various exploits. I thought the idea was quite appealing, a feeling a bit confident after a fairly extensive article authorship decided to take up the task.

And so, for the next several months I was focused on effectively doing a brain dump of my knowledge on security. The process was extremely educational, since to explain any concept a far greater knowledge then the one needed to simply apply a fix is required, plus writing a book as I have learned is just “a tad”

more complex then an article. But with the help of Marco, my technical reviewer and Martin Streicher who has done a tremendous job at cleaning up my ranting, I think we've got an excellent PHP security resource. The book itself is 201 pages, a bit longer then anticipated, but gave me the opportunity to cover each topic in a fair amount of detail.

Table of Contents

Input validation
Cross-site Scripting Prevention
SQL Injections
Code Injections
Command Injections
Session Security
Securing File Access
Security Through Obscurity
Sandboxes and Tar Pits
Securing Your Applications

The goal of the book is to introduce each type of vulnerability and to explain in greatest amount of detail possible what can lead to it and what are the possible consequences. In my opinion before solving any problem you should have a full understanding of it, so that the fix ends up addressing the cause and not the symptoms. As far as consequences go, it is imperative to know why a problem needs to be fixed and not allowed to linger. If you’ve ever came across a situation where someone dismissed cross site scripting (XSS) or other security problem as a non-issue, this book will serve as an excellent resource in demonstrating how even the most "trivial" exploits can be abused to great effect. Not to leave you handing so to speak, the book also spends a fair amount of time talking about possible solutions to each problem and provides deployable solutions for each one. In addition to talking about specific security issues, it is my sincere hope that it will encourage developers to think about security when designing and auditing their applications and ultimately lead to a better and a far more secure code.

At the present time the book is available via phparch.com website in both paper and electronic forms, and will shortly (within 1-2 weeks) appear on Amazon and Barnes & Noble, ISBN: 0-9738621-0-6. I should mention that the 1st 300 copies sold will be signed, so if you want my doodling

on your copy, hurry up and buy it.

Tuesday, August 23. 2005

FUDforum 2.7.0 Released Posted by Ilia Alshanetsky in FUDforum, PHP at 09:55

Comments (0)
Trackbacks (0)

FUDforum 2.7.0 Released

After a fairly short incubation period, 2.7.0 final is now available for download.
Installation Script
Upgrade Script

The release was made a bit faster then anticipated in response to a rather serious security problem found in the uploaded avatar handling code. All who use FUDforum and allow forum members to upload custom avatars are encouraged to upgrade immediately.

The details of the exploit are not being released at this time, but believe me when I say that the problem is quite serious and you should most definitely upgrade if you use the uploaded avatar functionality.

Aside from the fix for the security problem, this release integrates a number of other changes and improvements, in particular a much improved in terms of speed forum topic view generation code.
Continue reading "FUDforum 2.7.0 Released"

Monday, August 22. 2005

MD5 Dictionary Attacks Posted by Ilia Alshanetsky in PHP, Stuff at 10:28

Comments (15)
Trackbacks (0)

MD5 Dictionary Attacks

While on my daily news crawl, I came across a site (http://gdataonline.com/seekhash.php) offering a free and very quick service designed to decode md5 hashes. The principal used here is a dictionary attack; the operators of the site build a reasonably large, 12 million & counting, database of hashes and their corresponding values. All you need to do is specify a hash and if they got it in their database in less a then a second you get to see its corresponding value. While compromising weak hashes via dictionary attacks was never that hard, it did require wasting some time and processing power in application such as John the Ripper (http://www.openwall.com/john/) trying to find the equivalent value. Now, you can do it quite effectively (I’ve tried) via this online tool in fractions of a second.
Given that many PHP applications (my own included) store passwords as hashes rather the clear-text, it now raises the needed to encourage users to be a bit more creative with their password strings. Use of high-ASCII characters, liberal use punctuation characters and a like are easy but affective tools at defeating dictionary attacks, which are based on a relatively limited data range. After all md5 is 2¹²⁸, no one is going to offer the entire range of hashes, not to the general public anyhow

P.S. The hashing site is written in PHP

Saturday, August 20. 2005

PHP & Floating Point Math Posted by Ilia Alshanetsky in PHP at 16:25

Comments (5)
Trackbacks (0)

PHP & Floating Point Math

Came across a rather “interesting” peculiarity in PHP, which affects mathematical operations involving floating point numbers. Before getting into the details, let me introduce you to the problem I was trying to help a friend solve. The goal was to take an arbitrary floating point number, let’s say 1.841243, and convert it to a whole number where decimal points became part of the whole, so 1.8432432 would become 18432432. The first solution was a very simple scriptlet, which if C has taught us anything should’ve worked.

PHP:



<?php



$a = 1.8432432;

while ((int)$a != $a) $a *= 10;



?>

This code relies on 2 premises, which are true in PHP:
1) Casting a float to an int, results in a drop of decimal points. (Ex. (int) 1.8432432 => 1)
2) By multiplying value by 10, all decimal places will eventually be gone and (float)$a will equal (int)$a.

While both premises are true, the above code does not work, in fact, it results an unterminated loop, YIKES!
Continue reading "PHP & Floating Point Math"

Tuesday, August 16. 2005

Security Implications of ... Posted by Ilia Alshanetsky in PHP at 16:12

Comments (3)
Trackback (1)

Security Implications of var_export/print_r

Yesterday I've discovered an "interesting" implication of using user input inside var_export() and print_r() functions. To those who have never used the two, a brief overview of their functionality. The var_export() function takes a variable and represents the data found within as a valid PHP string. By default this string is dumped to screen, but if you want you can have it be returned as a string, by passing a 2nd optional parameter as boolean TRUE. For example if you wanted to put an array creation code into a file, you'd do something like this:

PHP:



<?php



file_put_contents("my_file", var_export($array, 1));



?>

The print_r() function is similar in function, except the returned data is intended for debugging and not storage. As with var_export() by passing a 2nd optional parameter you can force the data to be returned as a string rather then dumped to screen.

Herein lies the problem, when it comes to storing the data, this is done by enabling output buffering of the content without a set buffer size limit. Consequently, by forcing the function to generate a massive string it is possible to launch a denial of service attack aimed at exhausting both processor and memory.
Continue reading "Security Implications of var_export/print_r"

Thursday, August 4. 2005

OSCON 2005 Posted by Ilia Alshanetsky in PHP at 14:39

Comments (2)
Trackbacks (0)

OSCON 2005

Finally got a semi-stable internet connection, a pretty amazing thing during a convention of this size. So, while George is serenading the audience with the wonders of DBXML, I get to do a bit of blogging

.

The conference so far is a great deal of fun, had a chance to meet with many developers from other non-PHP projects, which is quite neat as most conferences I have a chance to attend to be PHP specific. The brief talk on performance I gave yesterday went rather well, with probably one of the largest audiences I've had at a conference and seemed to have gone rather well. The slides, to those interested are now available online (just click "talks" link at the top of the page and scroll down).

While for me OSCON is almost over :-(, I got an early flight back to Toronto tomorrow the next two conferences are already in the works. I will be speaking at php|works Conference in Toronto around mid-September and I will be giving quite a few talks at International PHP Conference in Frankfurt in early November.

Wednesday, July 27. 2005

IE -> Mozilla Code Migration Posted by Ilia Alshanetsky in PHP at 14:41

Comment (1)
Trackbacks (0)

IE -> Mozilla Code Migration

Came across a rather interesting article by IBM on how to convert IE specific web apps to work with Mozilla. Aside from the obvious, by listing the different approaches each browser adopts it serves as an excellent resource for making a web app cross-browser complaint. I hope they will update article with the other two commonly (relatively) used browsers, Konqueror/Safari (KTHML Engine) and Opera.

Monday, July 25. 2005

cURL and parse_url() tweaks Posted by Ilia Alshanetsky in PHP at 15:01

Comments (3)
Trackbacks (0)

cURL and parse_url() tweaks

With the release of PHP 5.1.0b3 the dev tree has been closed for new features, allowing only bug fixes to facilitate the stabilization of the code for the upcoming (don't ask me when) 5.1.0 stable. This however created a unfortunate situation where PHP does not have a development tree for feature enchantments, so any improvements remain lingering on developer's boxes until development tree is once again available...

In the past few weeks I've been doing some work, which involved using parse_url() and cURL extension quite a bit and in the process came up with few improvements.

parse_url() tweak [ patch ]

This patch adds a 2nd optional parameter to parse_url() which allows the function to return a particular URL component rather then an array. Ex:

PHP:



<?php



$host = parse_url("http://www.ilia.ws/gallery/", PHP_URL_HOST);

echo $host; // will print www.ilia.ws 



?>

cURL improvements [ patch ]

The patch does two things; first of all it allows the user to retrieve the request sent by cURL to the server. I found this to be very handy and necessary when trying to analyze the full content of the client to server communication.

PHP:



<?php



$ch = curl_init($url);

curl_setopt($ch, CURLINFO_HEADER_OUT, 1); // track request information

curl_exec($ch);

curl_getinfo($ch, CURLINFO_HEADER_OUT) // retrieve sent request as a string



?>

The second part of the patch introduces the convenience function, curl_setopt_array() that allows setting of multiple configuration directives via a single PHP function call. The array of option is based on option name, numeric CURLINFO key and its value.

PHP:



<?php



$ch = curl_init($url);

curl_setopt_array($ch, 

array(CURLOPT_RETURNTRANSFER=>1, CURLINFO_HEADER_OUT=>1));



?>

Thursday, July 21. 2005

FUDforum Layout Contest Posted by Ilia Alshanetsky in FUDforum, PHP at 13:05

Comments (2)
Trackbacks (0)

FUDforum Layout Contest

In the past few years FUDforum has grown quite a bit in both the offered functionality and the user base. However, aside from a few tweaks the layout of the forum has remained largely unchanged. While the current layout works quite well for most people, there is a clear want to update the layout to something more interesting. Hence this contest, the goal being to devise a new better, faster and prettier default theme (layout) for the forum, which would improve the user experience. Aside from a new and improved default template some additional templates maybe included in the stock distribution to give forum deployers greater flexibility as far as appearance out of the box.

So, if you have some spare time and would like to help to improve FUDforum please submit your design entries, more information can be found here:
http://fudforum.org/forum/index.php?t=msg&goto=26425

Wednesday, July 20. 2005

AOL Browser Woes Posted by Ilia Alshanetsky in PHP at 11:04

Comments (13)
Trackbacks (0)

AOL Browser Woes

A few days ago I received a bug report from a FUDforum user about his forum members having trouble staying logged in when using the AOL 9 browser, herein to be referred to as POS. According to him after logging in and browsing a few pages, the user would suddenly find themselves being logged out from the FUDforum. This happened on seemingly random pages, with no common element in between making tracking down the problem ever so enjoyable. The following is a nightmarish tale of me trying to resolve this problem, which hopefully serve as a clue to the developers who encounter the same issue.
Continue reading "AOL Browser Woes"

Thursday, July 14. 2005

Path Disclosure and PHP Posted by Ilia Alshanetsky in PHP at 16:57

Comments (12)
Trackbacks (0)

Path Disclosure and PHP

In the past few days I've been testing a number of my own applications and scripts as well as various bits and pieces of applications written by others that I use, using an automated scanning tool I have written. One particular issue I came across, common to all applications is the inevitable "path disclosure vulnerability". The premise behind this so called vulnerability is that remote attackers by specifying certain value can make the script report it's own location on disk. Theoretically this combined with another vulnerability could be used to do *something* or rather then potentially could be bad. As you can probably tell, I don't see this as a something to be terribly concerned about in most cases.

To demonstrate consider the following, most PHP function that take strings as parameters, like our favorite validation functions such as htmlspecialchars(), addslashes(), and so on will raise warnings when values they are passed are arrays rather then strings. This means that to get the path of the script, you simply need to pass the arguments as arrays rather then expected strings and then simply read the warning message generated by PHP to see the error.

PHP:



<?php



// script.php?name[]=foo instead of expected script.php?name=foo



$name = htmlspecialchars($_GET['name']);



// will emit: 

// Warning: htmlspecialchars() expects parameter 1 to be string, 

// array given in /path/to/script.php on line  2



?>

To solve this problem there are just two solutions:
1) Disable displaying of errors to screen and instead log them to a file, so if the Warning or Notice regarding array being used as a string is emitted, it won't be shown to the user using the site. This can be done within the script through:

PHP:



<?php



ini_set(“display_errors”, 0);

ini_set(“log_errors”, 1);

ini_set(“error_log”, “/path/to/php/errors”);



?>

2) Meticulously go through the code forcing PHP to cast the data to the desired type, via (int), (float) or (string) casts, this too will eliminate the Notice or Warning message.

Monday, July 11. 2005

FUDforum 2.6.14 Released Posted by Ilia Alshanetsky in FUDforum, PHP at 09:41

Comments (0)
Trackbacks (0)

FUDforum 2.6.14 Released

After nearly 2 months of development FUDforum 2.6.14 is finally out. Aside from the usual bug fixes this release includes a number of important improvements, such as full support for PHP 5.1 and introduction of a PDO database driver support, which enables FUDforum to talk with SQLite in addition to MySQL and PostgreSQL.

In addition to all of the changes in found in RC1 and RC2 there is a small number of modification made since then, a list of which can be found below.

The installer and the upgrade script can be found at their usual locations at:
http://fudforum.org/download.php and all FUDforum users are encouraged to upgrade.
Continue reading "FUDforum 2.6.14 Released"

« previous page (Page 13 of 15, totaling 225 entries) next page »
Frontpage

Guide to PHP Security