Skip to main content

Posts

Showing posts from March, 2013

Security is a moooooving target

Earlier today, I had a "free heart attack" when a new thread showed up on the PHP Internals list:

[RFC] more secure unserialize()

I love serialize()/unserialize() because it is nice and easy to use. Unfortunately, with ease-of-use comes greater responsibility. In this case, it is important that users can't submit their own serialized data structures to the server. When the server calls unserialize(), it expands out any data type, including objects. Upon destruction of an object, __destruct() is called by PHP automagically, which then executes whatever code is in there. The "free heart attack" I mentioned earlier came from the fact I send serialized data to the SSO client in the encrypted cookie. Fortunately, a look at the encrypted cookie code revealed I had been using json_encode() and json_decode(), which allowed me to breathe a sigh of relief. For now.

This just goes to show that security is a moving target. Or, if you are a cow, it is a mooooooving…

Just use grep! Don't use find + grep (+ xargs + whatever)...

I've been looking for an alternate to find + grep under Linux so that I can do similar queries to 'findstr' under Windows such as:

findstr /sic:"my_function" *.php

Recursive search for PHP files containing the string "my_function". The typical response to "how to search for some type of file containing some text" under Linux is usually along the lines of:

find "*.php" -exec grep -H "my_function" {} \;

Not only is that cryptic and longer and more difficult to type, it fires off a new, separate process (grep) for every PHP file it finds. I've seen a zillion incarnations of the above. Every time I run that, I end up waiting ten times longer than I would have waited for 'findstr' for the same operation. find + grep performance is terrible. So I said to myself today, "Hmmm...maybe grep has the solution already?" Lo-and-behold, it does:

grep -nir --include="*.php" "my_function"…