Writing

Internal Type Juggling in PHP 5.2 vs PHP 5.3

There is an undocumented case where the output of an internal function is different in PHP 5.2 vs PHP 5.3 when you pass it an invalid argument.

For example, strlen returns different values and warnings/notices when attempting to pass it an array.


php 5.2 > var_dump(strlen(array()));
PHP Notice: Array to string conversion in php shell code on line 1

Notice: Array to string conversion in php shell code on line 1
int(5)


php 5.3 > var_dump(strlen(array()));
PHP Warning: strlen() expects parameter 1 to be string, array given in php shell code on line 1
PHP Stack trace:
PHP 1. {main}() php shell code:0
PHP 2. strlen() php shell code:1

Warning: strlen() expects parameter 1 to be string, array given in php shell code on line 1

Call Stack:
467.9296 320928 1. {main}() php shell code:0
467.9296 321072 2. strlen() php shell code:1

NULL


The E_WARNING and return value of NULL in PHP 5.3 is preferred, but I still wanted to know why PHP 5.2 was returning int(5). I tracked down the reason to this subversion commit and this patch.

In the above patch, I see that strlen and other functions(method_exists, property_exists, function_exists, strcmp, strncmp, strcasecmp, strncasecmp, defined, is_a_impl) were not using zend_parse_parameters to get the arguments. This was preventing the standard validations and warnings from running for that function. Also, those functions were incorrectly casting the arguments to string with convert_to_string_ex. That is why strlen() of array() is int(5); because, casting array() to string returns “Array”.

Now, in PHP 5.3, those functions will no longer coerce the arguments to strings, will return NULL, and will issue a warning when invalid arguments have been provided. Thanks stas.

Note:
There is an extra space between the words php and shell in this post since the string “php[SPACE]shell” causes ModSecurity to prevent me from saving this post.

Google Dictionary Discontinued

I used to link users to the definition of a word by using the following url:
http://www.google.com/dictionary?langpair=en|en&q=protean
As of August 5, 2011, going to that url just takes you to a discontinued page that says “Google Dictionary is no longer available. You can use Google web search to find definitions or Google Translate for your translation needs.”.

Google suggests that you use
define protean
to display the definition of the word above the search terms, but it doesn’t take the user directly to the full dictionary entry.

You can use this url to forward users to the full dictionary entry for a word.
http://www.google.com/#q=protean&tbs=dfn:1

The tbs query parameter affects what Search Tool is displayed. Here is a list of other values that are available for that parameter.

Search Tool tbs value
Sites with images img:1
Related searches clue:1
Timeline tl:1
Dictionary dfn:1
Reading level rl:1
Social frim:1
Nearby loc:n
Translated foreign pages clir:1

Don’t Use maxlength on Password Inputs

On the HTML input form element, you must define a type and may define a maxlength attribute. This is in regards to the password type and the relation it has to the maxlength attribute. If the maxlength on a password input is wider than the width of the input, there is no way to tell if what you are typing (or pasting) is actually going into the field.

Below are two test forms that will illustrate my point. Each form looks identical, but have much larger implications in practice. Test the following KeePass generated password in the following forms:

f7cef761bb0c51db6811c27a752bff49

What you have just experienced is a problem that exists on many website’s user registration. If this were a real user registration, the password you entered will not completely save and you will be locked out when attempting to log in. This happens when sites validate the length of the password by specifying a maxlength as opposed to correctly checking its length during the form processing. Overall, using client side markup to validate form values is precarious. Therefore, maxlength should be limited to text input types, if it is backed up by server side validation.

P.S. Stop putting maximum length requirements on passwords, period. Just hash the password and store that. And no, password retrieval is not an excuse; have the user reset their password instead.

Creep Traps for Dating Websites

Free dating sites such as Plentyoffish.com or OkCupid.com tend to be flooded with creeps. Creeps here are defined as users who harass others with inappropriate messages.

Most women who have been on these sites have at least one story of a guy sending some ridiculous email with an incredibly offensive suggestion or perhaps an indecent picture attached.

A strategy to mitigate the effects of these creeps is two fold; first, identify these profiles, and second, prevent these profiles from continuing to creep.

An option for the first part would be to create a “creep trap”. Ideally, this would be a profile of a fictional woman with attractive pictures and a generic profile. Messages sent to this profile would then be scrutinized for their quality. If they contained ads, an over the top request, or are written like a text message, the senders profile would be flagged.

As for the second part, I do not think this is taken advantage enough in services such as these. Some sites are diligent and do ban troublesome users, but with the internet it is easy enough to create another profile. Instead, the site can quietly sandbox the user. To them it seems as though their emails are being sent; though, in reality, they are deleted and their profile is not viewable by anyone else.

The specifics of how many creep emails over a period of time should cause a user to be sandboxed is up for discussion, as well as sandbox duration. Overall, I would imagine this would amend the creep problem as well as improve user confidence.

Load-bearing Code

The term ‘load-bearing code’ can be used to refer to software that exhibits the following attributes.

  • Has no documentation or automated tests
  • Written by an ex-developer
  • Used by a large portion of the code base
  • Supports critical system processes

This term was inspired by its memorable use by Cosmo Kramer in the Seinfeld episode “The Chicken Roaster”: Jerry, these are load-bearing walls, they’re not gonna come down!

I have encountered load-bearing code from legacy open source applications, inherited projects or debugging production software.