|
Thursday, July 21. 2005FUDforum 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. 2005Thursday, July 14. 2005Path 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: 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: 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. 2005Monday, July 11. 2005Molson Indy 2005
Spent the entire Sunday at the Molson Indy in Toronto, here is the
photographic evidence. For the most part it was a rather enjoyable show, the main regret is the fact that this year another layer of netting was put up keeping the regular folk like me even further from the track, a closer look, costs $160+ a pop. Interestingly enough the best spot to see the most difficult track is from a non-paying zone on a little hill. Some of the latter photos were taken from there. Friday, July 8. 2005Webhosts have had enough!
It seems web hosting companies are finally coming to grips with something most security experts have known for quite some time, phpBB is inherently insecure. According to Netcraft
some are taking the steps to prevent further exploitation via this application by banning its usage on their servers. As per usual phpBB developer's response, they are denying blame and claim such moves are unwarranted, but given their security record during the past 6 months alone this is hardly surprising. Not only are new issues being found, because the developers can't seem to do an security audit, but new versions re-introduce bugs (2.0.15 re-introduced the flaw exploited by Santy worm) that have previously been solved. I hope other hosting providers will take notice and adopt the same strategy, not only for phpBB2 but for any application with a consistent history of security faults for which the developers do not wish to take responsiblity for. As well as failing to take the time to conduct an extensive security audit of their code. Tuesday, June 28. 2005Saturday, June 25. 2005PDO_MySQL Buffered Query Support
PHP 5.1 is well on its way towards release, so very little time is left to sneak in forgotten or missing features into it. One very handy (IMHO) feature that I've added to the PDO MySQL driver is the ability to toggle usage of buffered queries.
Up until now any query executed would be unbuffered, which limited you to operation with just a single result cursor at a time. The only way to avoid this limitation was to use fetchALL() method to pre-fetch results into array and then use them. This however is not always possible or practical as I've found out in the progress of adding PDO support to FUDforum. So, what do you do when something is lacking in PHP? Write a patch of course! As of yesterday you can set PDO_MYSQL_ATTR_USE_BUFFERED_QUERY attribute to TRUE to enable buffered queries and FALSE to disable them. PHP: Wednesday, June 15. 2005Tuesday, June 14. 2005PHP bind support via stream context
Up until a few days there was no way to tell PHP from which IP address to submit requests when making connections on a multi-ip server. PHP would automatically pick the 1st external IP and use it deliver external data. To address this limitation, I've added a context option that allows to you to bind an IP from the available local IPs and use it, rather then the default to initiate the connection.
PHP: The "socket" wrapper option "bindto" takes a ipv4 or ipv6 address as well as a port, binds the connection to it. Using the port is not necessary in most cases, if you simply wish to bind to a certain IP, specify it followed by ":0" as shown in the example. Tuesday, June 7. 2005Long Live PHP!
Today is the eve of PHP's 10 anniversary, could anyone had guessed that what started as a little Perl script would evolve into a scripting languages powering millions of sites all over the globe.
My 1st experience with PHP came around 1998, when the ISP I was using at the time was quite mortified by the load my Perl (CGI) scripts were causing on the server. Their suggestion was to switch to PHP, which supposedly offered performance and would help me not kill server, this was back in the day when PHP 3.0.X was king. As a programmer coming from a C background, PHP was a welcome break from Perl, a language seemingly designed for obfuscation. The thing that impressed me the most about PHP was the online manual, which rivaled many books in clarity and ease of use and a thriving community of users willing to share the knowledge about the language. It was another 2 years before I made my 1st contribution to PHP in a form of the shmop extension that provided quick & simple interface to shared memory for PHP. Since then I've been slowly making contribution, eventually taking a very active role in the development of the language in the past two years. Now a days, I spend a fair bit of my free time developing extensions, coming up with new features and of course solving security & performance issues. For the last year in a half it has been my privelege to act as PHP 4.3 release manager, finally passing on this mantle to Derick Rethans who will be RMing PHP 4.4. In comparison to all the programming languages I've had the pleasure of using PHP has been by far the most influential. For many years now PHP related projects have been my main source of revenue, whether through script development or development of custom modules. It was essential to the development of FUDforum, the fastest most secure bulletin software around, which now comprises vast majority of company’s business. It even helped me to travel the world and as a speaker at various PHP related conferences. On the eve of this momentous occasion, I would to thank Rasmus for developing PHP and his continued efforts at improving it as well as on occasional good word about FUDforum. While without Rasmus PHP would not exist, its growth would not be possible to the hundreds of volunteers who continue to spend countless hours at improving the language, my sincere thanks for all your contributions. Let’s hope that for the next 10 years PHP continues to grow at even a faster pace. Saturday, June 4. 2005Compiler Halt Patch, is in!
A few months ago I proposed a patch that would permit stopping the Zend Parser at a certain point in the script and not having it try to examine any subsequent content. The logic behind this feature was to simplify the process of creating single-script installers, such as the one used by FUDforum. The installer is a single script that at the end of it contains a code archive of the application being installed, which the installation process places into the set locations. The problem with implementing such installer at this point was that the data must be made PHP safe, so no <?php or similar "start-php-context" tokens that may be present in the archive are not treated as such resulting in undesired code execution. The solution required either encoding of the data using base64, making it 30% large or custom encoding scheme that would “hide” anything resembling a PHP start tag. Even with this problem solved, one last issue remained, this being the memory limit. Since the Zend Parser takes the entire script it needs to allocate memory for storing the archive that can be several megabytes large, this allocation quickly exhausts the default 8meg limit and causes a fatal out-of-memory error. By gaining the ability to stop the parser, this can be avoided since the data beyond the stoppage point will not be examined.
The main downside of the originally proposed patch was it provided no easy way to determine where does the archive portion of the file starts. The developer would need to parse their own script looking for the “STOP” point to determine the end of the script and the start of the archive. Given an overwhelming support for this feature, Zeev Suraski decided to rewrite the patch to include an easy way to determine this position. After some hacking on Zeev’s part and a fair bit of testing on mine a new patch was created and today applied to CVS. The patch provides a __HALT_COMPILER() construct that can be used to stop the parser and a __COMPILER_HALT_OFFSET__ constant indicating the “script-end” position. Here is a brief example of it’s usage: PHP: Output: some archive data, which can be binary The output of the code will be just the archive data, which can now be fetched without having to manually look for the "stop" portion inside the file. Kudos to Zeev for taking the time to improve on my idea and developing this patch, which as of today is part of PHP 5.1. Friday, June 3. 2005Do people really care about security?
A few days ago a friend of mine sent me a URL to an online store with a product he found interesting. When I went to the site, aside from the aforementioned product I saw a nice "Hacker Safe" logo, with the date (current date) which was supposed to assure me as a consumer that this site is "safe". Clicking on this logo took me to a page of a security company specializing in "helping sites protect you (the customer) from identity theft and credit card fraud", sounds good, I feel much safer already.
Curios about the truth of the site's hacker-safe claims, I decided to do a very basic test for Cross Site Scripting (XSS) by adding a small HTML string in the place of one of the parameter values in the get query. Imagine my surprise when rather then rejecting the clearly bogus value (number was expected, but non-numeric string was supplied), my input and the HTML tags found within were displayed verbatim. This little oversight would allow anyone to inject arbitrary content to be displayed as part of the store’s front end and if it contained HTML/JavaScript have it be parsed and executed. For example it would be trivial for someone to inject some JavaScript capable of stealing the current user's session and use it for their own gain. Identity theft here we come… Once the initial novelty of finding a trivially exploitable XSS bug in a fairly large online retailer, I've decided to send them an e-mail detailing the problem and its possible consequences in the hope they would fix it. Two days later, which goes to share just how much they care about security, I received a response, which goes like this: Thanks for your e-mail. Although what you've sent us is certainly interesting, it would definitely not qualify as a hacker attack. Apparently in today's security world session theft via XSS only classifies as interesting, I suppose only a full blown trojan or a virus would constitute a hacker attack. Deciding that perhaps a brush off was just that and the problem was fixed I went to site and entered the same XSS string as before. Lo and behold the bug is still there, even a day later, 4 business days since the initial report the XSS is exploitable as ever. It would seem that adding a simple input validation check is beyond the capability of the store's web development department, nor are "trivial" things like XSS detected by a supposedly reputable "anti-hacker" firm. Which leads me to the question, do people really care about security or are they simply interested in a token logo, which somehow supposed to make their customers safe and give them somebody to blame when things go wrong? With this attitude in place is it all surprising that every week there is yet another report about a large compromise in one company or another… Sunday, May 29. 2005session_regenerate_id() Improvement
A few days ago a I noticed an interesting behavior in the session_regenerate_id() function. When it renames the session id it does not remove the old session, leaving it active and potentially usable by a would be hacker. This does not pose a problem if the function is only used during new session create as the means of preventing session fixation, which is the intended use btw. However, it makes it completely useless if used on each session based request to prevent session leakage via HTTP_REFERER and similar, since the previous session id is still usable. It also means that changing the id on “actions” as some scripts to do prevent session theft also is pointless; in fact it doubles the amount of session ids for the same user making it only simpler to assume their identity. Furthermore it means that on every call to the function there is duplication in the number of sessions entries that will hang around until they are considered expired and removed by the garbage collection process.
For this reasons, I have added an optional parameter to session_regenerate_id() in PHP 5.1, if set to true, it will force the session extension to remove the old session on an id change. Thursday, May 26. 2005Google Web Accelerator and the dangers of prefetching
A few days ago I read an interesting blog entry on Chris Shifflet's blog about Google Web Accelerator (GWA) and how it affects PHP applications. The purpose of the GWA is to accelerate the web page loading speed and thus improve user experience. This is done through a series of techniques which involve different caching mechanisms, periodically downloading copies of frequently accessed pages and prefetching.
The prefetching works on a basis of a premise that when you load a web page you will not view just this page, but also click of a few links from that page. So, rather then waiting for you to click those links, while you are reading the current page, the browser is prefetching the content of the linked pages in the background. By the time you decide to click on the next link, its content is already sitting in browsers cache and can be loaded instantly. Pretty neat trick, right? While it is a neat trick, it does present several serious problem that affect both the webmasters and the users themselves. Let's start with the webmasters, since after all that's a bit closer to heart  Continue reading "Google Web Accelerator and the dangers of prefetching" |
|
|||||||||||||||||||||||||||||||||||||||||||||||||
