Let’s face it: error handling in PHP is crap. Actually it’s worse than crap, it’s craptastic. The core has almost no support at all for handling errors. Sure, PHP has a robust error reporting and logging system, but it has no real way of handling those errors. If you want to write robust code, you need to be able to actually handle errors. So how can we handle errors in PHP?
The other day, an article popped up in my feed reader that had a very interesting title (to me at least), Simple and Secure Login Script. As usual, I decided to click the link and give the article a read. Not overly shocking was the fact that I didn’t find the content of the article to be, how shall I say this…, overly factual. It’s not really a “tutorial”, but more of a “here’s some code that’s secure”. A quick review of the code found more than one vulnerability, and some significant things that I would change about it (as well as a few “really bad practices”).
So, rather than write a “rant post” about the code, I’ve decided to take another tactic. In this article, I’m going to walk you through my process for performing a security code review. Inline with the review, we’ll take note of any issues that we do find, and number them. Then at the end of the review, we’ll go over each one and look at potential mediation that we can apply and how to fix the issues.
The upcoming release of PHP 5.4.0 includes a plethora of new features, including Traits. While I do believe this is a great feature with great possibilities, I also fear that it may fall into the category of often-abused-features such as eval(), goto, constants, the @ operator, class inheritance and regular expressions.
When we talk about “random” numbers, we generally talk about two fundamental properties: Predictability and Bias. Both are closely related, but are subtly different. Predictability in reference to random numbers is the statistical problem of predicting the next value when knowing any number of previous values. Bias on the other hand is the statistical problem of predicting the next value when knowing the distribution of previous values.
As promised, I’m going to post the slides from last night’s talk on XSS prevention with PHP here. There was a fair turnout, with a few following the live stream of the talk. I must thank those who came, as there was definitely some good interaction and questions.
Today an article popped into my feed reader that raise my eyebrows. The article’s title is “Building Secured Web Applications Using PHP - The Basics“. The summary of the item looked interesting, so I decided to open it up…
What I found blew me away. It was filled with loads of bad information including some down-right wrong suggestions. Let me go through point by point and shed some light on the subject…
Well, my next talk is scheduled! It will be June 30th, 2011 at NYPHP. It’s the first of a series of talks in collaboration with OWASP, going over each of the top 10 vulnerabilities. This talk will be on Cross Site Scripting (XSS).
Hello all. It’s been a little while since my last post, but I haven’t disappeared. In fact, I’ve been quite busy…
I have always been intrigued by projects such as PHP.JS. To be completely honest, it’s not because I though they were “neat” or “innovative”, but because they have always made me ask myself “Why would someone seriously want to do something like that?!?!?”… Let me try to explain my standpoint.
In the first post of this series, we looked at some fundamental concepts of Web Application Security, and introduced the concept of Filter In, Escape Out. In today’s post, we will be examining the single most prolific vulnerability plaguing web applications today: Cross-Site Scripting (otherwise known as XSS). Not only is it prolific, it’s also commonly under-estimated and is often just a low priority after-thought. In reality, XSS is a formidable threat and needs to be treated as such.