click
-
Posts
138 -
Joined
-
Last visited
Posts posted by click
-
-
Matt's Formmail is a Perl script. I don't think this script is based on it at all.
-
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.
-
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.
-
My understanding is that other users and their scripts should not be able to access your account regardless of the permissions you've set. But, you're right, if you don't even need the feature then why risk it.
-
That should be easy enough to fix. For the .htaccess stuff, use the NC flag to make the Rewrite Rules case insensitive.
RewriteRule ^redirecturl1\.aspx$ redirect_script.php [NC,QSA]
On the PHP side, I think you should be able to use something like array_change_key_case(). Follow the link for more info.
-Steven
-
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");Steven
-
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.
-
There's a handy mod_rewrite cheat sheet (and a bunch of other good info) here.
-
I believe "RedirectMatch 301 ^/wp/.*$ http://www.mysite.com/catchall.html" should do it.
-
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.
-
Is this the only .htaccess file on the site? Make sure it isn't being overridden by another .htaccess in a subdirectory or something.
-
Just a hunch here, but I think the problem may be that the embedded player isn't sending the HTTP referer so it fails the first "!^$" condition.
-
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
-
I will keep tracking this thread just in case someone figures out how to define html mime version and content type in fullbackup.php so that when you set $debug=1; you recieve html instead of plain text email.
Just curious... Why do you want to keep $debug=1?
-
$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.
-
To get it working with Norton, just make sure your network is listed in the trusted network zones. (Personal Firewall, configure, Networking tab, if I remember correctly) That should do it.
-
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.
-
My backup results are sent in plain text. There are html tags in your result email???
-
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)
-
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....
-Steven
-
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...
-Steven
-
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.
-Steven
-
Now I see why everyone around here is so fond of TCH. Even with all the emotion/frustration involved, if you're not happy, Bill will go above and beyond to make things right. (regardless of who's at fault)
If I could, though, I would like to make one very humble suggestion. The only (very minor) issue I have with TCH is that they seem to be a bit aggresive with deleting posts here. Maybe you could consider replacing deleted messages with or something similar rather than simply making them go away. It can give the impression that there may be something shady going on. I once asked a question in a thread that was later removed (presumably because of another user that was being quite critical of TCH - I don't think it was anything I said
) so I know how frustrating it can be to come back here hoping to find answers and finding out that it's been inexplicably tossed. As a new customer at the time, it made me wonder...Hopefully this won't be deleted - though even I could see the humor in that.
-
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.
Variables Passed With Url
in Scripting Talk
Posted
$_GET is simply an associative array containing all the variables passed through the url so you should be able to use foreach() to loop through them all.