A Proposal for a PHP "UserData" Class

The title of this blog is “Application Security Street Fighting”. It is based on an idea I am pursuing for a while now. The goal is to come up with a set of simple and reproducible techniques to secure applications. Personally, I favor coding in unstructured languages like Perl and PHP for all the wrong reasons: It is fast and I am able to focus on the result. For example the first version of DShield.org was created over a Thanksgiving weekend. It worked “great”, crashed hard on the first Slashdotting and set the server I build for cheap on fire during the Code Red outbreak. But it survived! (The fire destroyed some of the insulation on the power supply, but amazingly the server kept on running for another two weeks until I was able to replace it. The best $400 home made server I ever had).

However, you will not find much of the original code in the DShield site of today. I probably replaced it 3 or 4 times just that first year. Each time, I learned a bit more about PHP. On the other hand, the site would probably not exist if I had done it “right” the first time. Coding slow kills momentum and opportunity.

Now how do we code fast and safe? Most developers associate secure coding with slow coding. I think there are a few misconceptions when it comes to secure coding, and I would like to address some of them in this and future blog posts. In this post, let me focus on user input validation, one of my favorite topics.

How do I validate input securely using php? For deep and complex questions like that, there is only one answer: Google it! . The first link that came back for me was a page on Techrepublic, “Secure your Web Applications by validating user input with PHP“. The solution presented on this page gets some things right: It uses a PEAR library, “Validation”. Less code to write, less bugs to fix! At least the way I code, reusing code works always in my favor. But let’s look at the rest of the code:

// check name field
if (!$validate->string($name, array("min_length" => 1))) {
  $errors[] = "Error in NAME field";

Now you may want to argue the use of the “extract” command, but well, this is not the point here. The problem is that you need to first pull the user submitted data out of the super global array like “$_POST”, then you need to validate it. And you need to do this every single time. I can tell you, it gets boring quickly. Before too long, you will miss a spot. If you clean a kitchen floor, “missing a spot” means having a happy dog help you fix the problem later. If you miss a spot in your PHP script, you got a vulnerability! That’s right: As a developer, you have to get it right every single time.

Personally, I find user input validation one of the more boring parts when coding. I would rather make sure my business logic is soundly implemented. So let me talk about a different approach I got to like lately:

  1. Start out by pulling all the user submitted data into an object.
  2. The only way for you to get to the user data is to call an “extraction” function, which will also validate the data.

For example  a bit of pseudo code:

$oUserData=new UserData($_POST);

And this is what the class approximately would look like (pseudo code)

class UserData {
  protected $aData;

  function __construct($aSource) {
    /* pull data out of source and assign to $aData */
    /* and clear out $aSource */

  function getName($sLabel) {
    if ( is_name($this->aData[$sLabel]) ) {
      return $this->aData[$sLabel];
    return false;

Cool. So now we got a very simple mechanism to extract validated user data. As a developer, I need to write the validation functions only once. The constructor for the class should also clear out the initial unvalidated userdata to avoid accidents down the line.

I will expand on this idea in future posts. Again: The idea is to write secure code without getting lost in endless and boring input validation exercises. That’s what I consider “application security street fighting”. It’s not pretty, its not fancy. But it works. We need to find simple and repeatable techniques that work every time.

Examine HTTP compressed gzip content

For incident handling, forensics or troubleshooting purposes, packet sniffing is often used to understand the information exchange between two hosts.  HTTP traffic packets are often sniffed so that the full header and body can be revealed easily, especially on the server side. On the client side, most commonly used technique is to use a proxy tool like Webscarab to intercept the request. While making new exercise for my DEV422, I noticed some interesting behavior of how different programs handles the gzip compressed HTTP content.

Normally, if the server sends gzipped content to the client, it sends a special HTTP header indicating to the browser the content should be decompressed before rendering on screen, this is the header normally sent

Content-Encoding: gzip

When there is a sniffer or interception proxy in the middle, the condition is complicated, as these man-in-the-middle need to be able to decode to read the actual content.

Let examine how Webscarab handles gzipped content, here is an interception on response coming from server.

Webscarab gzip encoding
Webscarab gzip encoding

Webscarab shows a “X-Content-Encoding: gzip” indicating the gzip process had already been performed. The browser does not have to take any action as the content is already decompressed by Webscarab.

Wireshark, on the other hand is a simple sniffer, it doesn’t alter anything the user is able to view. Let’s see what Wireshark can see while sniffing packets on the wire.


Unlike Webscarab, Wireshark does not alter the headers and only shows what is actually transferred. At the bottom of the above screen cap, Wireshark is able to decode the gzipped data and show the HTTP data.

Everything is good so far, Webscarab and Wireshark essentially handled gzip data transparently by default.

Now, what if I follow TCP stream within Wireshark? This is a very common function used by a lot of users to view the full conversation between two hosts.

Wireshark follow TCP stream
Wireshark follow TCP stream

Wireshark Follow TCP Stream function does not decode gzip compression. The content is not decoded while displayed on screen.

While handling packet sniffer or using a man-in-the-middle manipulating HTTP responses, make sure you are aware that some compression encoding could be at play if things are not displaying properly on screen.