OT: Getting at source code of CGI scripts

[Anonymous Monk]

This node falls below the community's threshold of quality. You may see it by logging in.

[Corion]

On a properly configured webserver, there is no way to get at the source code of any CGI script. But you won't need any of that, as you only have to check out the latest version of the scripts you have in your source code management tool, and compare the output of this script against the output of the program running on the website.

The steps are quite simple:

1. Get a printout (or diff) of the output of your script and the productive output online.
2. Mark up where you think they modified your source code.
3. Contact your legal counsel to see whether pursuing this has merit. Especially ask whether your existing contract preventing them from modifying your script is valid.
4. Provided that your legal counsel says that you won't be laughed out of court, send them a notice that you suspect them to be in violation of your software license.
5. Either they restore your old version of the software, or tell you they already use a completely different software manufactured by somebody else. In both cases, they'll tell you.
6. End of the story.

Personally, I don't see why anyone would enter a contract for software creation where they don't have the right to modify the software that was customized to them, and I'm not sure whether your case would be a case in a court. You can simply cancel all support for them, and void your support contract with them, as they modified the software in a way that the support contract does not cover.

But nothing of this has anything to do with Perl, and only with contract law. And I am not a lawyer, and this is not legal advice.

[graff]

... check out the latest version of the scripts you have in your source code management tool, and compare the output of this script against the output of the program running on the website.

That might not be possible, if the script involves using data that is local to the server (e.g. a database, config files or whatever) to determine what the output should be. If the author doesn't have access to the currently running source code, then access to such other data is likely to be lacking as well.

Something like l3nz's idea below might be applicable, unless one of the customer's modifications to the source involves removing the self-identification logic.

[Roger]

I developed a forms input system for an organization and they have locked me out of FTP access to the cgi files .... Since I am locked out of FTP access is there a way I can get access to my cgi scripts or even get information like date stamps or size of scripts.

Ok, I assume that you used to have FTP access to the web server to upload/download cgi scripts, and your client has disabled your FTP log in. Unfortunately there should not be another way to get to the cgi scripts. Otherwise the web server would be insecure and useless. You could try to 'hack' into their system, but that is quite difficult and illegal.

...finding my way around unix file directories is not a strength of mine...

This is nothing to do with unix directories, this is about system security. Unless you have some sort of login to the system, setup by system administrator (root), you would not be able to gain access to it.

[l3nz]

I think that there should be no way of getting to your CGI sources, and that if they willingly locked you out of their systems any attempt to retrieve them bypassing the locks would be frankly illegal.

If I had sold a program that the user cannot modify, I'd have thought of a way to remotely check software integrity, like a hidden GET parameter showing your name in a not-so-evident fashion and a file digest for the running script (see Digest::SHA1, for instance), so that you can stand up in court and demonstrate that:

• You are the actual software author
• The script they run was illegally modified
Just my $0.02

[dws]

Our contract states they cannot change code without my permission.

This won't help with the scripts that you're currently locked out of, but in the future, build in a command to return (e.g., as "text/plain") a set of MD5 hashes, one for each of your components. To prevent your customers from simply replacing that command with a hard-coded print of the "correct" hashes, pass a parameter to the command, use the parameter to generate a new hash. E.g.,

    my $nonce = param('nonce');
    ...
    my $md5_script = md5_hex($script_body);
    my $md5 = md5_hex($md5_script . $nonce);
    print "$script: $md5\n";

Then, assuming you have an identical copy of the source on hand, pick a random number, calculate the hash values for your copy of the surce files, then pass that random value to the remove CGI, comparing the values that it returns.

[extremely]

And then, as the evil side of the equation, I keep the old unmodified version around strictly for handing to my customized md5_script hasher.

[graff]

Forgive me for saying so, but that strikes me as an odd sort of contract, especially when applied to source code written in Perl.

Presumably, your customer has paid you for the effort you devoted to software development, implementation and installation for this project. (If not, that's a separate issue for you to resolve.) That transaction having been completed, I think the more common practice in such projects is that the customer is able to alter the software as needed, in the all-too-likely event that the original installation must be adjusted to adapt to changes the overall web server environment, or to keep up with inevitable changes in the customer's desired artwork, etc.

If the intent of your contract was to ensure that the customer would be dependent on you to make all such adjustments in the foreseeable future, then my first reaction would be "Why agree to such a contract in the first place?"

In any case, enforcing such a condition in a Perl application not only runs counter to much of what is good about Perl as an application development tool, but also turns out to be virtually impossible to do in any rock-solid reliable way. For example, you could have delivered the source code for your app in "encrypted" form -- there are CPAN modules that support this -- but it is widely recognized that this form of hiding the source code is only a hurdle, not an absolute barrier.

I've seen a web app distributed by a vendor of NAS systems that used encrypted perl code, and I'll admit that it stopped me from trying to make some simple changes (which would have kept some lame-brained warning messages from clogging the root account's mbox at five-minute intervals...) We did have a support contract that should have led them to solve the problem once I reported it, but before they got around to that, we just ended up ditching that vendor and moving to another NAS solution -- there were other problems as well, and the closed nature of the system just made it all too cumbersome to deal with. Anyway, while I haven't done it myself, I gather that it's entirely possible for any encrypted script to be loaded for execution and then dumped to a file by the perl interpreter in such a way that the source code is in fact quite legible.

So you could try something like that next time (actually, the Acme::Bleach module might be as good a form of "encryption" as any). Or you might follow l3nz's suggestion, and include some obscure feature in your code that will do something unambiguous (but not unsafe) in terms of identifying the source code -- e.g. have it produce a hidden tag in the HTML output that reports the MD5 checksum of the script file being run, or something of that sort.

But when your customer cuts you off from direct access to their copy of your source code, there's no way to guarantee that this particular contract clause can be enforced, in the sense of using legally available evidence to prove non-compliance. And of course, they could decide to implement an equivalent solution some other way -- this is a common possibility with any perl application, and it certainly blurs the situation for your sort of contract.

[Anonymous Monk]

finding my way around unix file directories is not a strength of mine
That's why god made filename completion ...

[talexb]

[..] they have changed at least 2 scripts and violated the contract

This sounds like a legal question to me, and not Perl related. If you want to pursue the matter, contact the lawyer who drew up or reviewed the original contract for you. Otherwise, move on.