Helpful Information
 
 
Category: Development Articles
Webserver Security (Part II)

This was a really good article. It summarised the points to watch out for in a comprehensible way, and then said what could be done about them. Please can we have more articles by this author?

http://www.koehntopp.de/kris/artikel/
Articles by Kristian Köhntopp

http://www.koehntopp.de/php
de.comp.lang.php FAQ (German)

Most of this is in German language, though.

Hello...
I am writing a menu system and using perl, cgi and html, I am trying to find a way to
keep "unwanted" users from "short-cutting" into pages (modules) before they enter used and password. I've done this by using the cookies file as the "holder" of the uid/password instead of the <url?uid=xx&pass=yyy> format... obviously dangerous since it shows up on the Location entry of your browser screen. But, to use the Cookies file as I'm doing, how "secure" might that be for keeping other users from obtaining this data. The reason I'm asking is that since I can do a "vi" to the cookies file, can others (hackers) have the same "bad delight" in doing the same thing?...

For discussion...

John McCormick

Hi!

This article is very usefull for me.
bcos 2 weeks back I saw this problem from my server itself.

I logged into one of our vds thru FTP , i can able to down load the other domain name files (include server side program also).

So this one is very critical one.

I f any body know how to encrypt the server side program (instead of text source file).
using any method it may solve the problem

Hi..
<br>
<br>
if a hacker would be allowed to be logged into the same server as you are, it could be possible for him to have read access to your files.
<br>
<br>
in case your hostingprovider has security up a little, for example by chrooted homedirs, that risk is gone..
<br>
<br>
also, is the cookies file accessible for example from http://www.you.com/cookies
<br>
or something like that?
<br>
<br>
if yes, it would be safer to move the cookies file under the documentroot of the webserver
<br>
(e.g. /home/you/public_html/ is your webservers documentroot and
<br>
/home/you/cookies is your cookie file directory..)
<br>
<br>
that way you can have the cookies stuff included by means of php3 or cgi, but not have it directly accesible through the web..
<br>
<br>
also, there IS a way for some sites to read the data out of your cookies due to a bug in the cookie code on most browsers..
<br>
Netscape said to have fixed that but not everyone has upgraded that off course..
<br>
and I wouldn't be surprised if it's still a live bug in IE.
<br>
<br>
what could be a more wise idea is to store sesion keys in a secure directory on your webserver..
<br>
if your server supports e.g. SuEXEC (apache)
<br>
then it will only be readable by you and your cgi programs... SuEXEC doesn't work with php3 as far as I know.. unless perhaps you use the cgi version.. (I always compile it straight into apache)
<br>
<br>
website security depends on so many things, and there is always the risk of someone "sniffing" what users are sending to your server and what the server sends back..
<br>
The only way to prevent that is by going to a SSL setup, where all data between server and client is encrypted.
<br>
<br>
greets,
<br>
Sin

Hi,
<br>
<br>
wat exactly do you mean with you can download other domainfiles and include progs?
<br>
<br>
as in you have read access to other users homedirs?
<br>
<br>
that is a very critical and dangerous one allright..
<br>
<br>
the solution would be for the owner / admin of the server to install a better and more secure ftpserver...
<br>
<br>
I know for one about BeroFTPd wich we use,
<br>
Bero doesn't allow anyone to go outside of his / her homedir, therefor not being able to browse through someone else's data.
<br>
<br>
BeroFTPd is available for free (open source)
<br>
from:
<br>
ftp://ftp.sunet.se/pub/nir/ftp/servers/BeroFTPD/
<br>
<br>
this is only if we're talking unix/linux servers here...
<br>
<br>
In case of an IIS server, there is a way to secure it, but that's one discription way to long to put here... (and honestly, I hate IIS)
<br>
<br>
Arjan Koole
<br>
The Netherlands

Hi

I got your msg , thanks for reply
we have the server in US (linux with apache web server).

The above probelm is there in our server.
I informed him , but still they are rectified .

If you have time pls send your email address

Thanks and Regards
K.Mariya

Hi,
<br>
<br>
should be easy to fix on a linux box :-)
<br>
<br>
the addy: arjan@tch666.com
<br>
<br>
greets,
<br>
Arjan Koole
<br>
The Netherlands

In "Faking web requests" part. What is the meaning of " ~/www < cat test.php".

What do i have to put instead of " ~/www" there?

Utilizing a MAC (message authentication code) is the best way to protect data that can be modified client side. This works by sorting by key and concatenating all values of a GET/POST request... the resulting string is run through a one way hash and this hash is passed to the client w/ the rest of the key/value pairs. When another request is made, the application goes through the same process and compares both MACs... they should match unless the data has been tampered with. Perl programmers will want to use Digest::HMAC module to accomplish this. It works great.

Very good article, I now realize that using the http_referer variable simply doesn't do it security-wise. Anyone know a good tutorial on how to implement seesion id in php4 to replace the http_referer checking?

Thanks,

Sebastian

Webserver Security \(Part II\) (http://www.devshed.com/c/a/Administration/Webserver-Security-Part-II)

This second part of our two-part series on webserver security explores the problem of keeping private data in publicly accessible areas of you server and keeping data from untrustworthy sources from entering your system.

Please discuss this article in this thread. You can read the article here (http://www.devshed.com/c/a/Administration/Webserver-Security-Part-II).

If you would like to see an article covering a particular topic, please post your request here (http://forums.devshed.com/forumdisplay.php?s=&forumid=65).










privacy (GDPR)