Tag Info

Hot answers tagged

8

The standard way is to put the credentials into a config file, and attempt to protect the config file from being more readable than the perl file. This offers a moderate increase in security; for example, the code may be in source control and accessible to developers, the config file wouldn't be. The code needs to be in the web server's cgi root, and ...


6

Essentially it XORs two strings together and then executes the result. You can view the original code just by XORing the two strings and printing the result instead. I stripped off the ''=~('(?{'.( and ).'$/})'); bits and wrapped it in a print statement, and here's what I got: Some random malware (pastebin)


5

I often pass the password to the script in an environment variable that way the script need not have access to the secure location that contains the password. PASSWORD=`cat passwd_file` perl_script.pl then the script reads the password my $password = $ENV{'PASSWORD'} bonus points if the perl script drops privileges


5

I agree with Gilles that disabling perl is not effective security; as there are numerous other ways you could be attacked (e.g., a python script; a bash script; a php script; an executable) and that restricting /usr/bin/perl to certain users groups may have side effects (e.g., that program that calls a perl script as an ordinary user). However as an aside, ...


4

Disabling perl is useless. The exploit that can be written in Perl can also be written in another language. Say, PHP, which you obviously aren't going to disable. If you take a system that's already very secure (as in: vulnerabilities are rare and tend to affect only a small part of the system with no direct way of enabling the execution of arbitrary code), ...


4

You need memory. If the server does not remember who clients are and when they were last authenticated, and instead trusts the clients for keeping track of themselves, then the clients are in position to fool the server. What you describe (saving and then resetting the cookie) is called, in all generality, a replay attack. To see things conceptually, with ...


3

There are many ways in which a session management mechanism can fail and this could lead to severe security risks. As a good practice you should: Use HTTPS, so that the information in the cookies could not be intercepted in transit. Set the secure flag for the cookies, so that they are not sent over unencrypted connections. Set the HTTPOnly flag for the ...


3

As others have already said, put the credentials in a separate file which the script will load. Risks of having the password in the script include its being exposed to shoulder surfing, its being committed in revision control systems or configuration management systems and distributed far beyond what it should be, accidentally copying to another location ...


3

CERT has create a CERT Perl Secure Coding Standard and there's been discussion of having Perl::Critic have a set of policies that match their standard. As far as I know, nothing's been done yet. Here's the start of the discussion on the Perl::Critic dev mailing list.


2

Hmm, I'm going to have a stab at this. I'll probably fail, but here goes! First line is just the shebang for convinience of execution and to set warning mode. Not sure why warnings would be enabled for a script like this, but it's here. #!/usr/bin/perl -w The next line I've broken down. The first bit: '' =~ It's asking whether the next bit of code ...


2

The attack you are experiencing is called a Remote File Inclusion (RFI) technique. It's basically the outcome of a vulnerable web application which is being taken advantage of to upload malicious code to spawn a remote shell. You do not need to specifically disable Perl. You can start identifying the vulnerable application like for example phpBB that the ...


2

Try "Perl::Critic". I haven't used it yet but i came across the answer of a similar question in the below link: http://stackoverflow.com/questions/1149447/perl-code-security-scanner-other-than-rats-must-be-static link to the Perl::Critic details: http://search.cpan.org/~thaljef/Perl-Critic-1.118/lib/Perl/Critic.pm


2

Can he point out the section in the PCI DSS Requirements an Security Assessment Procedures 2.0 which he is using to justify this? It's not quite clear if the problem is the fact that it's third party code, or that it's sourced via a collectively managed repository. If this is only a PCI-DSS audit, then argue your case: PA-DSS does not apply to payment ...


1

This script begins by require './lib.pl', which will read and execute the contents of the lib.pl file, from the same directory. Without seeing the contents of this file, your question is (provably) unanswerable. The generic method for reverse engineering is: do things in due order. The script engine will read the script code top-to-bottom, left-to-right. It ...


1

He thinks that we should have someone from the outside audit all the code from CPAN we want to install. This person would need to have strong security background and deep knowledge of Perl. Unfortunately, they don't know anyone like that. Well why doesn't he think the same for the rpms? It just seems riskier to him because he feels lost there. But it's ...


1

The consensus seems to be: The password should be in a separate file, not part of version control, and protected with permissions more restrictive than that of the script. Encrypting the stored password is a waste of time since the script needs to be able to decrypt the password anyway. But I'm thinking of adding a third control on top of those: Time Based ...



Only top voted, non community-wiki answers of a minimum length are eligible