Re: [cgiapp] Re: URL Encryption
Mark, The problem I'm having is that the report section of my app needs to be viewable to users without a password (as per the client's request) but our client has many clients, each of whom may have access to different reports. Our client will be sending each client a URL for each report they are able to view. I never really know which reports our client will deem viewable by which of their clients, so I need an easy / secure way to make sure 'Client A' that receives /report.cgi?id=200 can't URL hack the id=200 to be id=199 which may be a report meant for 'Client B'. I could come up with a quick solution using crypt() on the reportid and including the result in the arguments along with the report id: /report.cgi?id=200enc=a23dj7923h or possible doing a simple encryption on the report id itself /report.cgi?id=2dj872. I was just wondering what techniques other people are using to get around this same challenge. --- Steve Comrie - Original Message - From: Mark Stosberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 06, 2003 10:31 PM Subject: [cgiapp] Re: URL Encryption On 2003-10-06, Steve Comrie [EMAIL PROTECTED] wrote: I know there's a couple people on the list that have mentioned it before and I haven't had a use for it up until now, but what techniques / CPAN modules are being used to encrypt static URL's to prevent URL hacking? By static URL, I assume you mean a GET style query string, not just the URL of a static page. My applications tend to be (Postgres) database backed. Often I pass around primary ids of table rows (instead of the data). Or, if a user has some data that is specific to them, it can be stored in session table, and just the session_id is passed. Lately, I've been using CGI::Session for that, and I will be start using my own CGI::Session::PureSQL module with it soon. PureSQL stores data in the standard database way of one value per column, rather than the default CGI::Session method of serializing all the data into a Perl data structure in a single DB column. That will be released on CPAN once its cleaned up a bit. I noticed that someone wrote CGI::Session::Auth, which adds extra functions to check for logged_In and so forth. I may look more into that module as well. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: URL Encryption
All, You could generate a token- an MD5 hashed random string that you then associate with the report and the user via a server-side DB. Your client can then mail these URLs that have these tokens in them to your client's clients. The URL will be totally indecipherable and untamperable. You'd need to create a little app to generate and manage these tokens (or build it into your system) but that shouldn't be too bad. When a request comes in with a token attached, check it for validity against the DB and show, or don't show, based on what you find. This is pretty much how the backend of CGI::Session works, btw. -DJCP On Tue, 2003-10-07 at 05:43, Steve Comrie wrote: Mark, The problem I'm having is that the report section of my app needs to be viewable to users without a password (as per the client's request) but our client has many clients, each of whom may have access to different reports. Our client will be sending each client a URL for each report they are able to view. I never really know which reports our client will deem viewable by which of their clients, so I need an easy / secure way to make sure 'Client A' that receives /report.cgi?id=200 can't URL hack the id=200 to be id=199 which may be a report meant for 'Client B'. I could come up with a quick solution using crypt() on the reportid and including the result in the arguments along with the report id: /report.cgi?id=200enc=a23dj7923h or possible doing a simple encryption on the report id itself /report.cgi?id=2dj872. I was just wondering what techniques other people are using to get around this same challenge. --- Steve Comrie - Original Message - From: Mark Stosberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 06, 2003 10:31 PM Subject: [cgiapp] Re: URL Encryption On 2003-10-06, Steve Comrie [EMAIL PROTECTED] wrote: I know there's a couple people on the list that have mentioned it before and I haven't had a use for it up until now, but what techniques / CPAN modules are being used to encrypt static URL's to prevent URL hacking? By static URL, I assume you mean a GET style query string, not just the URL of a static page. My applications tend to be (Postgres) database backed. Often I pass around primary ids of table rows (instead of the data). Or, if a user has some data that is specific to them, it can be stored in session table, and just the session_id is passed. Lately, I've been using CGI::Session for that, and I will be start using my own CGI::Session::PureSQL module with it soon. PureSQL stores data in the standard database way of one value per column, rather than the default CGI::Session method of serializing all the data into a Perl data structure in a single DB column. That will be released on CPAN once its cleaned up a bit. I noticed that someone wrote CGI::Session::Auth, which adds extra functions to check for logged_In and so forth. I may look more into that module as well. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dan Collis Puro GeekUprising Internet Consultants http://www.geekuprising.com [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: URL Encryption
Hi, There are a couple of ways to do that then. You can either place a checksum in the query string, using MD5. Or You could encrypt all the details in the string and then decrypt it when they call it. Or In the database or whatever holds the report you could generate a unique hash and store that in the DB and supply them with that in the query string. That way you just look up the report on the param in the query and use that. There are many ways to do it. The last one would be the quickest to execute as you are not, generating hashes or encrypting\decrypting each time. Adam - Original Message - From: Steve Comrie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 10:43 AM Subject: Re: [cgiapp] Re: URL Encryption Mark, The problem I'm having is that the report section of my app needs to be viewable to users without a password (as per the client's request) but our client has many clients, each of whom may have access to different reports. Our client will be sending each client a URL for each report they are able to view. I never really know which reports our client will deem viewable by which of their clients, so I need an easy / secure way to make sure 'Client A' that receives /report.cgi?id=200 can't URL hack the id=200 to be id=199 which may be a report meant for 'Client B'. I could come up with a quick solution using crypt() on the reportid and including the result in the arguments along with the report id: /report.cgi?id=200enc=a23dj7923h or possible doing a simple encryption on the report id itself /report.cgi?id=2dj872. I was just wondering what techniques other people are using to get around this same challenge. --- Steve Comrie - Original Message - From: Mark Stosberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 06, 2003 10:31 PM Subject: [cgiapp] Re: URL Encryption On 2003-10-06, Steve Comrie [EMAIL PROTECTED] wrote: I know there's a couple people on the list that have mentioned it before and I haven't had a use for it up until now, but what techniques / CPAN modules are being used to encrypt static URL's to prevent URL hacking? By static URL, I assume you mean a GET style query string, not just the URL of a static page. My applications tend to be (Postgres) database backed. Often I pass around primary ids of table rows (instead of the data). Or, if a user has some data that is specific to them, it can be stored in session table, and just the session_id is passed. Lately, I've been using CGI::Session for that, and I will be start using my own CGI::Session::PureSQL module with it soon. PureSQL stores data in the standard database way of one value per column, rather than the default CGI::Session method of serializing all the data into a Perl data structure in a single DB column. That will be released on CPAN once its cleaned up a bit. I noticed that someone wrote CGI::Session::Auth, which adds extra functions to check for logged_In and so forth. I may look more into that module as well. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.522 / Virus Database: 320 - Release Date: 30/09/2003 - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: URL Encryption
On 2003-10-07, Steve Comrie [EMAIL PROTECTED] wrote:
I could come up with a quick solution using crypt() on the reportid and
including the result in the arguments along with the report id:
/report.cgi?id=200enc=a23dj7923h or possible doing a simple encryption on
the report id itself /report.cgi?id=2dj872. I was just wondering what
techniques other people are using to get around this same challenge.
Steve,
You are on the right track here. I'll elaborate on what other people
have said. The key to a system like the above is having a secret key
that comes from a config file and is not publically available.
To generate enc, you create a checksum using the report_id and the
secret as the seeds, like this:
# untested
sub gen_id_md5 {
my ($secret,$id) = @_;
require Digest::MD5;
my $md5 = new Digest::MD5();
$md5-add($secret,$id );
return $md5-hexdigest();
}
Before running the report, you take the ID received, generate
it's checksum again, and compare that to the enc received.
Even if someone understand the checksum system, they should have difficulty
generating a valid one without knowing your secret.
Mark
--
http://mark.stosberg.com/
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: URL Encryption
On 2003-10-06, Steve Comrie [EMAIL PROTECTED] wrote: I know there's a couple people on the list that have mentioned it before and I haven't had a use for it up until now, but what techniques / CPAN modules are being used to encrypt static URL's to prevent URL hacking? By static URL, I assume you mean a GET style query string, not just the URL of a static page. My applications tend to be (Postgres) database backed. Often I pass around primary ids of table rows (instead of the data). Or, if a user has some data that is specific to them, it can be stored in session table, and just the session_id is passed. Lately, I've been using CGI::Session for that, and I will be start using my own CGI::Session::PureSQL module with it soon. PureSQL stores data in the standard database way of one value per column, rather than the default CGI::Session method of serializing all the data into a Perl data structure in a single DB column. That will be released on CPAN once its cleaned up a bit. I noticed that someone wrote CGI::Session::Auth, which adds extra functions to check for logged_In and so forth. I may look more into that module as well. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
