Life and software

I recently picked up “Programing PHP 2nd ed” and I was dismayed to see the DB chapter. Don’t get me wrong any programing book that does not cover DBs is not complete. My problem is that it discusses runing SQL strings and it mentions placeholders in passing, and preparing statements as performance feature. Given today’s web environment and the multitude of sites that suffer from SQL Injection attackts most of them being scripting (asp,php,ect..) they should it make a point when mentioning placeholders, that, whenever user input is being passed to the DB place holders should be used.

I’ve interviewed many developers that can not tell me what the advantage is for using place holders other than in prepared statements for performance reasons. The most important reason to use place holders is to prevent malicious user inputs from corrupting your sql.

Take for instance a user login function might do something like this:

  $rs = $db->query("select * from users where user_name = '" + $user + "'");

Instead of

  $rs = $db->query("select * from users where user_name = ?", array($user));

the difference in this two pieces of code is that if I pass “x’;delete * from users; select * from user_name where user_name = ‘x” to your login function the first code would execute the whole string as 3 different sqls effectively wiping out your users table. Meanwhile the second approach will return no rows unless there is a user with that as a user name.

There are countless posts about escaping/scrubbing user input prior to using it in DB scripts and most of them fail b/c there are too many ways to get around it. The sad part is that by using prepared statements or atleast placeholders the DB will do the right thing every time. This should have never been an exploit in the first place. ALL intro books to DBs in any language should point this out.

SQL injection is in the no 2 security vulnerabilities for web applications. It costs millions of dollars every year and it is absolutely unessesary. Whith a little education of the programing masses SQL Injection attacks would be a thing of the past. Then we can concentrate on XSS and why we need to escape user input on the way out as well

I’m picking on PHP, but I’ve interviewed many (actually most) java developers (with 8+ years of expericence) who tell me that you use prepared statements for performance reasons and are shocked to find out about bad user input and SQL injection (the only reason we don’t see more SQL Injection attacts in big java apps is b/c frameworks like hibernate are used and they do the right thing.) This is a very sad statement since those are the same people building our financial infrastructure…. But don’t worry I don’t hire anyone who can’t answer that properly….

I’ve been on a javascript kick lately and started doing some projects, some for google gadgets, but all for fun. The basic requirement for the projects are for them to be done entirely in client side javascript (no server side code). This is nice b/c anyone can do a view source and figure out what is going on, which is great for learning. Upon this end I decided to start playing with javascript’s ability to do image processing, and while I found a bunch of projects (a combination of client side and server side) nothing seem to fit my needs.

Then I came across this post and the flickr services and their json feeds. And I forgot about image manipulation. Basically you can get any of the flickr feeds in a callback json format.

<script>
    function jsonFlickrFeed(o){
        // do somethign with the feed
    }
</script>
<script
  src="http://api.flickr.com/services/feeds/photos_public.gne?tags=&tagmode=any&lamp;ang=en-us&format=json">
</script>

Whith that little bit of code you can have a flickr feed loaded into your web page when the page loads.

Once you got the json feed you can select the image size you want (by default the feed comes with _m):

<script>
    image.src = feed.items[i].media.m.replace(/_m/, '_o');
</script>

where:

• _s small square 75×75
• _t thumbnail, 100 on longest side
• _m small, 240 on longest side
• [none] medium, 500 on longest side
• _b large, 1024 on longest side (only exists for very large original images that were resized during upload)
• _o original image, either a jpg, gif or png, depending on source format

see Flickr hack: All Sizes for all pics for more details

See it in action with a little game also available for igoogle

Next I got more creative and used a little ajax. Here I had to cheat and put a php proxy on my site to get away with XSS.

<script>
    function loadMoreImages(url, tags) {
        try {
            var req = new XMLHttpRequest();
            req.open(
                "GET",
                "/gadgets/proxy.php?url=" + encodeURIComponent(url),
                true);
            req.onreadystatechange = function() {
                if (req.readyState == 4 /*complete*/) {
                    eval('(' + req.responseText + ')');
                }
            };
            req.send(/*no params*/null);
        } catch (error) {
        }
    }

  loadMoreImages('http://api.flickr.com/services/feeds/photos_public.gne?tags=' +
                            tags + '&tagmode=all&lang=en-us&format=json');

</script>

And by calling loadMore images with different tags I can get as many images on the fly, even with user input. Currently I get the images from the url parameters tagName.

Once I have as many images as I want I can do some fancy stuff…

See Flickr Rain also available for igoogle

Then I got silly and nostalgic, and decided to build a game out of it. A few event handlers later I got this monstrosity

The web is filled with wonderful things, specially now that massive data feeds are being opened up for us to play with. I can’t wait to see other json feed implementations out there. I hope ebay opens up their APIs for something like this soon.