• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 270
  • Last Modified:

guidlines for basic security when using CGI

when i browse this url:
http://www.mysite.com/cgi-bin/myCGI.exe/test1?accountid=12345
the browser displays private info like:
account name is: bill

i don't what every body to be able to exctute myCGI with some parameters.
i want only users that went through authenticated process (which is another story - not discussed here), will be able to exctute myCGI.

there must be stndard ways to dill with such thing... right?
0
ewilde
Asked:
ewilde
  • 6
  • 4
  • 3
  • +1
2 Solutions
 
ZvonkoSystems architectCommented:
right!
For that are httpd.conf of the web server and .httpacces in the CGI directory.
And if you want to allow anonymous access to the CGI script and want to restrict some CGI parameters, then is the only way to do that in the CGI script. The logoc is: if the REMOTE_USER is empty and restricter params used, then redirect to login.htm or some page that forces logon and redirects back with same parameters.



0
 
ewildeAuthor Commented:
would you please explain in details what are  httpd.conf of the web server and .httpacces ?
0
 
ZvonkoSystems architectCommented:
Thanks Michel.

In httpd.conf look for the Protection, Protect, Pass and Exec statements. There are already some. Use them as template.
For .htaccess you can read the description here: http://httpd.apache.org/docs/1.3/howto/htaccess.html
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
ahoffmannCommented:
> i don't what every body to be able to exctute myCGI with some parameters.
as said before, either use .htaccess (apache, iPLanet, most other web servers, but somehow different in IIS)
or use your CGI with a form-based login which then is independent of the web server
0
 
ewildeAuthor Commented:
i thought about the following logic:

in the first login proccess the user supply username and password.
the browser then generate random code (with a script like : new Date().getTime().toString() ) and send the code along with the username and password.
once the CGI verified successfuly the user name and password, it than generates another random code, save this code along with the code sent by the browser, and also send this code to the browser (as a respond to the browser's login request).
the code generated by the CGI is the code for the next request for this specific browser.
in the next request (for example - "account history") the browser send both, the code sent by the CGI  and the code it generated before (in the login request) along with other request parameters.
the CGI suppose to verify that both of the codes match to each other, before responding with the requested "account history".


why do i have a hard filling that i'm trying to invent a wheel...
0
 
ZvonkoSystems architectCommented:
because you try to reinvent the wheel!
Use the .htaccess

In that .htaccess you can store the userids and passwords and do not have to care about it anymore.

My impression is that you generate your own problem by putting both functionalities in same CGI, the functionality for anounymous users and the functionality for authenticated users. Separate the authenticated functionality to a new CGI and and redirect to that CGI on authenticated method calls. The web server will then handle the authentication for you.

To see what user logon you see in CGI look for the CGI environment var: REMOTE_USER

0
 
ahoffmannCommented:
you method sounds very good, and most major websites with billions of values to sell/hide need to have such a method ;-)
Why would you do it this way? Is there a need for such a strong method?
0
 
ewildeAuthor Commented:
(still haven't checked those tips yet....)

Zvonko,

by using this method the user will be automaticaly prompt for authentication by the browser (right?). but what if i want to design my own login-web-page...? and also, it would be quite inconvenient to mange a ~1000 of users using the command line, right? are there any visual tools for such task?


ahoffmann,

you are not the first one who noticed i'm a "genius" :-) (http://www.experts-exchange.com/Databases/Microsoft_SQL_Server/Q_21763284.html)
but didn't you mean something like that when you "said":
"use your CGI with a form-based login which then is independent of the web server"?
0
 
ZvonkoSystems architectCommented:
I know of a good tool to manage thousands of users on a web server: Lotus Notes Domino!
0
 
ZvonkoSystems architectCommented:
Hello ewilde, here a few basics about web authentication. First of all is http from the beginning NOT a session based protocol. It is a one time shot and response protocol. To handle access to URLs there was a authentication method added which is named "basic authentication". That basic authentication is NOT the recommended authentication method because it transmit the entered browser password in nearly plain text (it is base64 encoded) and it transfers that password header with EVERY page and page element, that does say with every image requested from that authentication region (called Realm in http). The bad news is that basic authentication is the only authentication built in browser software to be handled automatically on http return code 401. Once the password is entered in browser it stays in storage and you cannot log off from that realm without closing all browser windows and starting browser from scratch.
Because of that all disadvantages do the most web servers offer an authentication method which is not browser controlled. The common name for that web server controlled authentication is application log on or web page log on. You see the difference when basic authentication is used then your browser pop ups a small dialog and not a whole page with some fields.
But for web page based authentication you have to know that once authenticated you have to carry any token with every http request after authentication to signal that you are authenticated. It would be a bad idea to transfer every time the password as token. Therefore every web server uses some session hash as authentication flag. For example, EE uses a cookie to store your user id and password hash (not the user id and password!) in a cookie to see for every request which authenticated user is requesting. Beside the cookie method there are also the form hidden field value hash ticket method and the query string parameter hash ticket method.

And the most important side of that web server based authentication method is that all the users and passwords needs to be stored in some sort of repository. The repository can be a text file or a database or operating system user check or LDAP user check or another web server managing user credentials (such web server are called directory servers).

So now you come along and say: I want to do the same :-)

In the upper picture some aspect are even not mentioned, like session timeout, authentication permission for read, edit, create, change, different permissions for different directories and document types and so on.


0
 
bryanlloydharrisCommented:
This has a section on security:
http://www.cookwood.com/perl/
0
 
ahoffmannCommented:
> but didn't you mean something like that when you "said":
sorry, don't knwo what you mean?
 Zvonko gave a good (still incomplete, as said) explanation of authentication methods.
I already said that the method you described sounds very good (should be used in a lot of web site, but isn't)-:
So, what else do you expect?
0
 
ewildeAuthor Commented:
i'm sorry for the delay, i had to leave this issue for a while.
although i did able to implement basic and digest authentication, this question is still open, for me. considerating a friendly user interface, i much more interested in a web page based authentication, i still havn't understand what is the standard/common way to deal with such thing, what is the standard/common way to encrypt the password (to get a password hash)?

anyway, i have certainly got great info from Zvonko and ahoffmann. i will accept this, and probably continue with another new question soon.
Thanks!
0
 
ZvonkoSystems architectCommented:
You are welcome.
0

Featured Post

Upgrade your Question Security!

Add Premium security features to your question to ensure its privacy or anonymity. Learn more about your ability to control Question Security today.

  • 6
  • 4
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now