ewilde
asked on
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?
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?
ASKER
would you please explain in details what are httpd.conf of the web server and .httpacces ?
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
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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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(
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...
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(
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...
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
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
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?
Why would you do it this way? Is there a need for such a strong method?
ASKER
(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" :-) (https://www.experts-exchange.com/questions/21763284/Results-missing-from-stored-proc.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"?
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" :-) (https://www.experts-exchange.com/questions/21763284/Results-missing-from-stored-proc.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"?
I know of a good tool to manage thousands of users on a web server: Lotus Notes Domino!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
This has a section on security:
http://www.cookwood.com/perl/
http://www.cookwood.com/perl/
> 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?
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?
ASKER
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!
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!
You are welcome.
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.