Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by click

  1. If I were you, I'd look into a different form script. Another forum I follow has people constantly complaining about the security issues present in formmail.php. Apparently it is easy to inject header information into the form, which can compromise your account, bog down your server, and get your account suspended. I'm not saying this is GOING to happen to you, I'm just warning you that it MIGHT.

    You can't really go by the name of the script; There are dozens of different scripts named formmail.php. From a quick look at the source to the script they were using, it looks like it should be secure against header injections.

  2. Permissions certainly do matter and affect security and file access. My point was only that on a shared server there should be other measures in place that keep users out of each other's accounts. Most scripts that use mysql databases contain mysql login info in plain text in their source/config files, for example, so you certainly wouldn't want other users to even be able to read them.


    So, I guess my real question is whether vulnerable scripts in other users accounts can access my account.
    No they can not.

    I would have to agree, though, that 0777 permissions should be avoided.

  3. I would just use a RewriteRule to redirect to it.


    >RewriteRule ^ImageDetails\.aspx$ redirect_script.php [QSA]


    The QSA flag tells apache to re-append the QUERY_STRING to the redirected address. This would make the query string available to the php script in $_GET['GalleryId'], $_GET['CurrentImage'], etc. The script would then lookup the new location and redirect. I think the php to do a 301 redirect is:


    >header("HTTP/1.1 301 Moved Permanently");
    header("Location: http://www.newdomain.com/newdir/newpage.htm");



  4. Everything after the "?" is stripped from the url and placed in the QUERY_STRING variable so you would need to test against that. Maybe something like:


    RewriteCond %{QUERY_STRING} ^GalleryId\=53\&CurrentImage\=3$

    RewriteRule ^ImageDetails\.aspx$ archives/byEntry/galleries/destinations/usa/central_california_coast/20040124_big_sur_sunset.php [R=301,L]


    1100 RewriteRules in your .htaccess certainly wouldn't be pretty though! You could maybe send all references to "ImageDetails.aspx" to a php script that could manage the redirects a bit more gracefully.

  5. Hmmm, now THAT'S an interesting comment. I don't understand the hotlinking code, but what is sending the HTTP referrer when a link to the actual file is on a web site? What are the specifics that make embedding the .asx to the files different from linking directly to the .asx? This is an interesting learning experience. :) ;)

    I don't know for certain, but I think the way it works is that when you link directly to a file, the web browser requests the file and therefore sets the HTTP Referer. When a media file is embedded, on the other hand, the web browser is simply handing the address off to a media player to play, so it is the media player that actually requests the file. If the media player isn't sending a HTTP Referer when it requests the file then it won't be blocked.


    I don't mess with embedded media much and haven't actually tried it out, so it's just a theory, but it would explain why the blocks seem to work for files being linked directly but don't work if they're embedded.

  6. Did you replace "example\.com" with your domain name? You should have this in your .htaccess.


    >RewriteEngine On
    RewriteCond %{HTTP_REFERER} !^http://(www\.)?altaredlives\.org/ [NC]
    RewriteCond %{HTTP_REFERER} !^$
    RewriteRule \.(jpe?g|gif|bmp|png|asx)$ images/nohotlink.jpg [L]


    The 2 "RewriteCond"s are what should stop it from blocking your own site. So your problem is probably there. There should only be one RewriteRule after the RewriteCond's too.


    What's the difference between the [L]and the [NC]?

    [L] = Last Rule - It stops processing the .htacess file after matching that rule, I believe.

    [NC] = Case insensitive - Matches both upper and lowercase

  7. $debug = 1;
    From: root@server115.tchmachines.com (Cron Daemon)

    That email was sent from "Cron Daemon."


    Since you have debug set to "1", fullbackup.php is just dumping the resulting web page to the cron daemon which is in turn emailing it to you. Since the cron daemon is sending the email, it is setting the headers and doesn't know anything about what's being sent. I don't think there is any way to change that.


    Unless you're trying to debug something, you should be able to set "$debug = 0" and let it email you through the "$notifyemail" address.

  8. I just looked at the script again. The only thing I see that would cause it to send you html is if you have $debug = 1. You should be able to set $debug = 0 and put your email in $notifyemail to get a text summary of the backup. The email should be from cpanel@yourdomain, not Cron Daemon.

  9. I forgot to ask, is there a way to specify in this script what folder on the remote FTP server to upload the backups to? I can do it when I do a manual backup through cpanel, but need a way to specify it through this script. Thanks!


    The remote directory is passed in "rdir" (&rdir=folder_name in the URL)

  10. Why not create custom error pages? 401.php, 403.php, 404.php?

    That would be far too simple! Actually, I do plan on making custom pages for the other errors (404, etc) but I'd have to look into making a 401 page since I'm not sure exactly how they work and I should be the only one using that folder so it didn't seem necessary.


    Anyhow, after researching it a little more, I don't think "default" for ErrorDocument works on apache 1.3, so I tried pointing 401 to a non-.shtml file that doesn't exist and it works great. Don't know why I didn't try that before... oh well. :)


    Until the next time I break something.... :eek:



  11. First, some background... I recently redid my site using PHP. I added "RewriteRule ^(.+)\.shtml$ /$1.php [R=301,NC]" to .htaccess to catch any references to the old .shtml files from search engines, links I missed, etc.


    Since I don't have any custom error documents, that caused a loop as apache would look for 404.shtml which would be rewritten as 404.php which would trigger another call for 404.shtml, etc. To correct this, I tried setting all the error messages back to the apache default using "ErrorDocument 40x default" in .htaccess but for some reason this triggers a 500 error. The end result, though, is that apache sends the default message with "Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request." tacked onto the end, which I figured was close enough for now. :)


    Anyhow, on to my problem... I have a directory set up to require authentication through .htaccess. When I try to access the directory, instead of getting a login prompt like before, I get a 404 page saying that /401.php could not be found. Removing the rewrite rule above, fixes it, which seems to indicate that apache is looking for /401.shtml and somehow finding it without the rewrite rule. So, best I can figure, apache is ignoring my .htaccess "ErrorDocument 401 default" altogether and using some phantom 401.shtml or something. Is there any way to force apache back to it's default rather than looking for a nonexistent error document? Why doesn't "ErrorDocument 401 default" work?


    Thanks for any help...



  12. Ahhh, this might be the problem. The error files are in the right place, they're just not showing up. I guess I need to add more content on the error pages as the largest one of the is only 6K. Thanks!! I'll be back if I have more trouble. Thanks GUYS!! You're the best!!


    :) Monica

    I believe the error pages have to be larger than 512 bytes, not kb.



  13. No they can not.

    Excellent! So a folder that is writable by user nobody is only vulnerable to scripts that I am running, then. I was concerned that someone hacking an old script in another user's account might be able to reach across the server and mess with my files.


    Thanks for your patience, everyone, and keep up the good work... I'll leave you alone now. :thumbup1:

  • Create New...