http://www.perlmonks.org?node_id=1002352

squimby has asked for the wisdom of the Perl Monks concerning the following question:

I've poked around a few websites (cgisecurity, and the OWASP project) and cannot find much for application testing tools and apps for LAMP servers running Perl--the only thing I've come across is pWeb suite from weaknet which I don't feel to confident in. Does anybody have suggestions for web application security testing tools? Furthermore, as a rook who was just appointed the task of researching this, would the tool need to be specific to Perl, or are most cross-language. I appreciate any info and/or guidance!
  • Comment on Web Application Security Vulnerability testing

Replies are listed 'Best First'.
Re: Web Application Security Vulnerability testing
by Your Mother (Archbishop) on Nov 05, 2012 at 17:19 UTC

    I think this is a great question for learning and I hope you get some good answers. Being the resident wet-blanket I proffer: professional web security is no place for a rookie. You will miss things and you will get things wrong. There are some decent, mostly commercial, probing/fuzzing tools but there is no way to automatically and accurately assess a site's security. A karate handbook can't teach a self-defense class and web-security program can't find/fix any but the most obvious and anticipated security issues in a website.

    To actually answer some of your post: cross-language tools are fine. HTTP(S) is all both sides have to speak so the client's programming language is irrelevant.

      Fortunately my company and boss know better than to trust me with actually implementing application security testing. I was just asked to find some resources and tools for further investigation by somebody who does in fact know what they're doing. Any advice for tools or resources--particular probing/fuzzing tools which you have a good experience with? It looks like OWASP has some good information, but from what I gather they don't make recommendations for enterprise solutions to avoid influence from corporate sponsors.
        Fortunately my company and boss know better than to trust me with actually implementing application security testing.

        Nice. But make sure everyone learns that even constant security checks won't prevent a clever attacker from finding an obscure path through your system.

        Once, one of my systems was tested by a well-known organisation for one of the clients. They found a problem with the login function: In a certain combination of operating system and database, it was possible to test account names for existence. So, an attacker could significantly reduce the number of combinations of names and passwords to be tested. Of course, this was not expected behaviour, and I removed that bug.

        But: They did not find a way in, so they did not test anything else. The client was happy with that, the system earned its "tested by $organisation" stamp, and now it was "secure" and could be used.

        It seems none of the testers even thought of calling technical support, pretending to be one of the users that (s)he found during the login tests and have the password of that account reset or revealed.

        None of the testers asked for a test account to try to attack the system from the inside.

        None of the testers asked for the source code.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re: Web Application Security Vulnerability testing
by sundialsvc4 (Abbot) on Nov 05, 2012 at 21:25 UTC

    Security is never a “product.”   It is a process.   Therefore, no security-testing “product, alone” would have any meaning, even if you did find one.   (And of course, you can.   Snake-oil sells well.)

    Having said all that, I do have a few idle thoughts about what I'd consider to be things that you should keep in mind with regard to the security of your Perl-based web site:

    1. Your Perl version, and your web-site software whatever it is, should be kept up-to-date.   This allows you to keep abreast of the updates that are from time to time provided by the various software suppliers.   Keep abreast of discussions that happen right here.
    2. Most intrusions into a web-site are actually “out-of-band.”   No one penetrated the defenses of the web-site:   they went around it, just as the Germans defeated the Maginot Line by rendering it obsolete.   Therefore, pay most attention to the operating-system environment, to the integrity of your shared-hosting vendor, and to thoroughly hardening your dedicated-host environment.   (For example, if you are using a “convenient” tool like Plesk, you are most-likely already $DEAD $BEEF, and don’t blame Perl for that.)
      • Somehow, this quote from the above-referenced Wikipedia article seems especially apropos:   “Generals always fight the last war, especially if they have won it.”
    3. The coding practices of your entire system must be such that a Bobby Tables attack cannot by any means be mounted.   No “magic tool” on the planet can help you with this:   either your code is invulnerable to it by design, or you are $DEAD $BEEF and the entire world (except you, fool) already knows about it .
    4. “Security” of a web-site is the kid-brother of “Total Reliability.”   It is completely astonishing to me how many production web-sites are out there which I can drop into 500 Internal Error just by innocently selecting a particular menu-option or pressing a particular button that the programmer did not bother to test.   (Quite literally, only one path through the application has ever been swept for mines.   No wonder the customers are unhappy.)   There are plenty of tools such as Selenium by which a thorough front-end functionality test can be built and automated, and even driven using Perl.   (There are, at this writing, 45 hits for “Selenium” at http://search.cpan.org.)   But it is very, very rarely done.
      • More than one time this year, I have been morally and pragmatically obliged to say to a (potential) client:   “Well, sir, before we can discuss enhancements to your web-site, first we must stabilize it, because right now I can drop it on its a*s more-or-less at will..”   This is not always popular ... or profitable ... but of course I won’t pick-up a client (or wish to, for I would surely lose much money...) whose understanding of their true business condition is less than realistic.

      That's good advice, and we already do all this--controls for regular system updates, definitions updates, input sanitizing, firewalls, permissive IDS, user access controls, backups, a disaster recovery location, quality control procedures, and periodic reviews for everything mentioned above all controlled by 2 system admins who have combined more years experience than years I have walked this planet. To continue with the war analogy--we want to make sure we're secure within our gates/borders. I know this is in fact a process, and I'm wondering just what tools are out there to test scripts/code for vulnerabilities (XSS, injection attacks, etc.).
Re: Web Application Security Vulnerability testing
by Anonymous Monk on Jul 18, 2013 at 19:19 UTC

    Not sure if you are still looking for an application security test, but Black Diamond Solutions is offering a complimentary scan.

    http://blackdiamondsolutions.com/partner/veracode/