sulfericacid has asked for the wisdom of the Perl Monks concerning the following question:

I had this problem once before so here I am again..looking for a real solution this time rather than a quick fix. I have a form which stores data into an SDBM database and some monkey head has went of their way to mess it up. It's messed up in a way I can't even figure out how to delete their data!!

http://sulfericacid.perlmonk.org/rac/rac/mark/delete.pl is the page I am working on. I am trying to get rid of the large paragraph that's there, please don't click on the other delete's!! I have a backup of the db, but just try the big one :)

I am doing a print-all on everything in the database and trying to delete the hash key, but for some reason on the messed up data it keeps saying "information not found!".

The script I am using to try and delete these evil things is:

use warnings; use POSIX; use CGI qw/:standard/; use CGI::Carp qw(fatalsToBrowser); # You are requested not to change any configurations in this file. # Everything is setup to function as-is, any tamporing may damage # the script. require SDBM_File; my %emails; my %snailmail; my $snail = "snail.dbm"; #change to location of snail mail databa +se my $list = "mylist.dbm"; #change to location of email database my $del = url_param('del'); tie %emails, 'SDBM_File', $list, O_CREAT | O_RDWR, 0644; if ( !tied %emails ) { print "database unsuccessful $!.\n"; } tie %snailmail, 'SDBM_File', $snail, O_CREAT | O_RDWR, 0644; if ( !tied %snailmail ) { print "database unsuccessful $!.\n"; } print header, start_html('Email Management'); foreach(keys %emails) { print qq($_ => $emails{$_} [<a href="delete.pl?del=$_">delete?</a +>]<br><br>); } if ($del ne "") { if (exists $emails{$del}) { delete $emails{$del}; } else { print "<center><font color=red>This data can not be found!</f +ont></center>";} }
On the email-add form itself, I tried to add my own "anti-hack" security and it worked..a lot better than not using it. What I used for each field was something that looked like this:
$name =~ s/</&lt\;/gi; $name =~ s/://gi; $name =~ s/TO//gi; $name =~ s/FROM//gi; $name =~ s/SUBJECT//gi;
Which removes all the nasty things that I can't have in my database because this connects to an emailer. Any tips on how to get my delete script to work to get rid of this crap would be very helpful and if you know of better ways to keep this data from getting into the DB to begin with, I am more than willing to learn the security I need.

Thank you!



"Age is nothing more than an inaccurate number bestowed upon us at birth as just another means for others to judge and classify us"

sulfericacid

Replies are listed 'Best First'.
Re: deleting hash keys (script has been tampered with)
by graff (Chancellor) on Mar 10, 2004 at 04:57 UTC
    When I did "View page source" on the cited page, I noticed that the one thing that set the trash entry apart from the others was the presence of line-feed characters in the database entry -- and in particular, the string being used as the hash key for this entry contained a line-feed as well. I'll copy the relevant part of the html source below with "[\n]" to show where actual line feed characters are present -- note that the "=>", which marks the end of the portion being used as the hash key, follows a line-feed:
    ...<br>jmathis555@aol.com[\n] To => jmathis555@aol.com[\n] To jmathis555@aol.com[\n] ...
    This stands out, because if it weren't for this one bogus entry, the whole list of one-line strings with "delete" links would have shown up in the html source with no line-feed characters at all. (Wouldn't it be worthwhile just to include a "\n" after each "delete" anchor tag in the html source? Makes it easier to "debug" the output...)

    Anyway, I'm wondering whether having the line-feed in the parameter string that is assigned to the 'href="..."' part of the "delete" link might have something to do with the problem.

    If that is the source of the trouble, then one thing you could do to prevent this in the future is to normalize every "\s+" to a single plain space before storing anything in the database, or at least before using a given string as a hash key. (Sorry I can't be more helpful at present.)

    update: On closer inspection, I'd bet money that the problem is being caused by having a line-feed as one of the characters in $_ when you include this string in the 'href="..."' parameter string. When I mouse over that "delete" link with the browser, the link target shows up, but only this much of it: "delete.pl?del=jmathis555@aol.com" -- the rest, as shown in the page source ("\nTo"), isn't being sent back by the browser -- the "\n" seems to terminate the link target. Since the last bit ("\nTo") is part of the hash key in your database, you can't get a match.