http://qs321.pair.com?node_id=482038

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

Hi,

I'm a little paranoid about my programming. I'm about to take on a project that consists of a membership area that in order for members to view, they must pay for a subscription fee. I'm thinking about using a third party cc billing company and once a user signs up, it has a script that will update the members database to tell my web application that he/she signed up.

Now since this will deal with money, there are always potential hackers who would want to eliminate competitoin or even receive free service. Thats just my thinking...you can call it paranoia. But the thing is, I'm confident that I can do the programming, but its how well I can do it. How would I know if its secure enough? That leads to my question whether if there are private companies that check how secure an application is and then tells you the loopholes you must fix? Or Can I do this myself? I'm assuming I'll need to read lots of hacking books and then see if those hacking tricks apply to my web application.

Basically I got most security features checked off my list:
tainting ssl warnings use strict form checking every inputted variable cgi.pm to disallow uploads and to have a certain max length to avoid D +OS mysql queries using placeholders and/ or having = '$taint_input' mysql user passwords using md5 session management using md5 session code (cgi::session) mysql is password protected (password is not shown in any perl scripts +)
The real downer is this is on a win2k system. Is apache more secure? I may recommend the company I'm working for to move it to a apache server. But the mysql database is located somewhere elsewhere other then the web server machine (I heard this was better).

Any recommendations of articles or books to read about security with membership sort of sites will be real nice.

Thank you all,
perleager

Edited by Arunbear: Changed title from 'Paranoia', as per Monastery guidelines

Replies are listed 'Best First'.
Re: Paranoid about web application security
by samtregar (Abbot) on Aug 08, 2005 at 22:20 UTC
    Any recommendations of articles or books to read about security with membership sort of sites will be real nice.

    Pick up a copy of CGI Programming with Perl. It has a good chapter on security as well as lots of other information you may find helpful.

    As an aside, one obvious item that's missing from your list is that you must not keep credit card numbers around longer than you need to. As soon as you've processed the transaction delete the card from your database. If it's not there then an attacker can't steal it!

    -sam

      It is a good book (I own it) but isn't there anything newer to recommend on this subject?

      Btw, I have your book, too. :-)

      (I liked "Writing ...", but it could have used a couple of hundred more pages about modules (chapter 7).)

        It is a good book (I own it) but isn't there anything newer to recommend on this subject?

        Nothing directly applicable jumps to mind. If you haven't already you might check out Applied Cryptography. It's a very useful overview of relatively modern cryptographic systems. In the same vein I find the author's newsletter, Crypto-Gram very informative.

        Btw, I have your book, too. :-) (I liked "Writing ...", but it could have used a couple of hundred more pages about modules (chapter 7).)

        Thanks! Chapter 7 was definitely the hardest to write in the book. I had grand plans for including many more modules and digging into the code in more depth but in the end I was happy to just get it done. It turned out to be quite challenging to present other people's work honestly and fairly.

        -sam

      As soon as you've processed the transaction delete the card from your database. If it's not there then an attacker can't steal it!
      It's not clear to me that this is always the safest option. Consider a shop where customers come back, and over time, do repeated purchases. If the shop doesn't store the credit card information, customers have to resubmit their credit card info for each purchase. So the shop reduces the number of credit card numbers stored in their on-line database (unfortunally, that doesn't mean the numbers are gone - good database management means keeping backups and transaction logs and those can stolen as well), at the cost of having more numbers floating over the network.

      (Further remarks are addressed to the OP)
      Security is more than win2k vs apache (which isn't a valid trade-off anyway, it's like saying "shall I have bread, or peanut butter" - you can run apache on win2k. You can make win2k secure, or leave it unsecure. You can set up apache securely, or unsecurely). It's more than the OS, web server, your code and any third party code. It's also the people - many credit card number thefts are inside jobs. Your code and setup can be bullet proof from the outside, it will be of no use if an operator makes a private copy of your database backups.

        It's not clear to me that this is always the safest option.

        Let's be specific - you're worried that an attacker could collect CC numbers by intercepting or viewing traffic between the browser and the client. You propose to reduce this risk by storing CC numbers in the database.

        This strikes me as a poor security trade-off. It reduces a rather unlikely threat (you are using SSL right?) in exchange for greatly increasing the value of your database to an attacker.

        Also, make sure you consider whether you're allowed to keep those card numbers on file. There are FTC rules about this and the CC processors have rules as well. It's quite likely that what you're suggesting is in violation of those rules. I'm sure there's a way to do this which is in compliance but I doubt it involves keeping CC numbers in the clear in your database. Perhaps the CC processors offer a reusable token?

        -sam

Re: Paranoid about web application security
by cowboy (Friar) on Aug 08, 2005 at 22:33 UTC
    • Have at least one other person look over your code. It's easy not to notice problems in your own code, that stand out to others.
    • See if any existing well known authentication systems fit, before re-inventing the wheel. Odds are they've been looked over quite well over time.
    • Keep it as simple as possible. Think any special security features through. It's not uncommon to add a feature meant to increase security, that actually makes it worse.
    • Obviously keep everything patched, but attempts at password stealing/sharing/brute forcing is more common than attempts to hack into a pay site. (at least the ones I've worked with)

    Hope this helps.

    Update: All the above advice assumes you're using a 3rd party processor, so you only have to deal with authentication, not actual credit card/payment data.
Re: Paranoid about web application security
by Anonymous Monk on Aug 09, 2005 at 00:10 UTC
    David Wheeler's Secure Linux Programming book is very good and contains lots of general discussion as well as language specific topics, including perl.
Re: Paranoid about web application security
by saberworks (Curate) on Aug 08, 2005 at 22:49 UTC
    If MySQL is on a different machine, you need to encrypt or otherwise make sure people can't sniff the data as it's going between machines.
Re: Paranoid about web application security
by neniro (Priest) on Aug 09, 2005 at 08:44 UTC
    What you wrote sounds good to me. I want to suggest to keep an eye on the network-security arround your app:
    • Use a (non-software) firewall to allow only needed traffic to your server.
    • Stop all unnecessary services on that box.
    • If mysqld is one of those services you could allow only connections from 127.0.0.1.
    • Use an intrusion-detection-system like snort.
    • Make someone responsible to do all security patches but remember to try those patches on a second box before you get hit by some nasty side-effects.
    • Continously keep an eye on the logs.
    • Plan the actions for a worst-case scenario!
Re: Paranoid about web application security
by basje (Beadle) on Aug 09, 2005 at 07:37 UTC
    One of the biggest threats to web applications is execution of uploaded exploits. This can lead to defacement, DoS or even privilege escalation and hijacking of your server.

    You already say you disallow CGI uploads, which is good, but not always practical. Plus there are other ways to upload (or generate) an executable file.

    If you need uploads, or just to save anything to disk (even config files, avatars etc), make sure that it is saved outside of the web tree. Never call it directly, but always through an intermediate script unless you can check it somehow. This to prevent a call to the file is used to execute code in any form.

    Also make any file you save non executable. As you are on windows, that is hard to do.

    If an attacker is able to execute scripts outside of the web tree, you have other problems anyway.
Re: Paranoid about web application security
by contradev (Monk) on Aug 09, 2005 at 08:35 UTC
    Regarding payment gateways, many tend to have pre-written code packs in multiple languages which I still tend to scan through to get a rough idea on how to interact with their systems. I find it easier reading (usually well commented) code than the reams of accompanying documentation.
    If you are new to e-commerce, I would advise using a gateway which hosts the CC payment forms which would at least take some of the security concerns away from you.

    Regards

    c

    `exit` and sleep;
Re: Paranoid about web application security
by nedals (Deacon) on Aug 08, 2005 at 22:53 UTC

    Only allow reasonably secure passwords..
    6 or 8 chars minium with both alpha and numeric chars.

      Yuck, yuck, and doubleyuck! All this means is that either
      • Everyone uses "test123" (or similarly stupid passwords)
      • They're like me and they use the same three "secure" passwords for everything
      • They write down their passwords on a sticky note and put it on their monitor
      • They put everything in a password vault and use an insecure password (like their son's name) for that.

      You cannot take the idiot out of the user, so plan accordingly. If I break into a user account, I shouldn't be able to do anything more than screw with that specific user. If I can bring down the site by grabbing a low-priv account, that's the problem. It's the user's responsability to choose and use a good password. It's your responsability to protect the other users when (not if!) they don't.


      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Paranoid about web application security
by samizdat (Vicar) on Aug 09, 2005 at 12:27 UTC
    I hope you've already done this, but I see so many sites that don't that it bears repeating. Make sure your users are already on a secure server SSL connection before they type in login and password.

    I would definitely push for apache over IIS on Win2k, if you can't get off completely to a 'NIX box. More flexibility, more modules, more security.
      SSH is not strictly necessary, only for transmitting confidential information (like transmitting orders, creditcard info and changing passwords). You can keep passwords perfectly safe over an unencrypted link.

      If you enforce logging in over ssh you get extra complications with cookies/sessions, unless the whole site runs under https.

      A safe way to use logins over plaintext is the following: Store only the md5 of the password in your DB (we'll call this md5pw here).

      Now, send a unique random number to the client (sessionId will work well). Have the client take the typed password, and (in JavaScript) do md5(md5(password)+sessionId). Send the result, along with the username. You can verify it on the server side easily, as you have the sessionId, the md5pw and the username. The password is never sent, and neither is the md5pw, only a sequence that changes with every session.

      Eve cannot do anything with it. Mallory could hijack the session, but you have that problem in any session based site. You can solve that by including a checksum.

      One could opt for this scheme and have the payments handled by a merchant, to which you would link (or use paypal). That would alleviate the need for the ssh, which would be a hassle to implement well under windows.

        If somebody has a login/pw form on their home page, I can't see how it is safe, unless they are doing what you suggest with every home page visit. Please enlighten me. :)
Re: Paranoid about web application security
by anonymized user 468275 (Curate) on Aug 09, 2005 at 13:10 UTC
    You'll never think of everything a hacker might try, or rather it is safer to assume so. My advice is to make sure the project has a properly-planned alpha phase where in-house testers follow a test plan and perhaps even deliberately hack the service before it goes on general release. This is not just to tackle security but other aspects of a business critical release. And after that an additional beta phase can check the satisfaction of a small group of selected customers whose feedback would be even more valuable.

    Such lifecycle decisions are not normally taken by programmers, but it covers your back if you at least recommended it.

    One world, one people

Re: Paranoid about web application security
by willyyam (Priest) on Aug 09, 2005 at 13:14 UTC

    Apache is securable, as opposed to IIS, which cannot be secured. Apache on Windows does present a challenge though, because any accessible file or region of memory is potentially executable.

    *NIX systems (Linux, BSBs, UNIX) can provide greater security through chroot jails and permission-based security. However, If you are not an experienced sysadmin with *NIX then the greater security of apache on *NIX may be negated by an inadvertent configuration error. OpenBSD is one of the most secure server systems, in that out of the box you can be reasonably sure that there are no significant vulnerabilities, and the most likely point of failure will be your script, which narrows your focus. In any case, you have lots of good advice above, so good luck. Security is not a solution, but a process involving vigilance.

      Apache is securable, as opposed to IIS, which cannot be secured.
      This sounds more like a statement of blind faith rather than a reasoned argument: I don't recall having heard of any disclosed vulnerabilities in IIS 6 (which is what you probably should be running as Windows 2000 has just gone out of support). Yes there were some absolutely horrible holes in IIS (I particularly remember the raw NTFS stream bug in IIS 3 with some amusement), but it strikes me that MS really are taking security seriously these days.

      Ideally you should have your web server behind a firewall anyway whatever OS it is running on, thereby preventing vulnerabilities in other parts of the OS making your web applications insecure.

      Of course if you know of any unpatched problems with IIS, maybe now is the time to be laying them out so the OP can make his own mind up based on the facts.

      Third party analysis of IIS 6 security can be found at:

      /J\

        I spoke too soon. I was unaware that IIS 6 was available, or that it was better than previous versions - but it is, and it appears to be. I still contend that any Windows server is less secure by default than something like OpenBSD (designed from the ground up to be secure - as opposed to Windows, which is designed from the ground up to be easy to use for the most people), but if placed behind a sufficiently configured firewall, IIS 6 will probably be okay.

Re: Paranoid about web application security
by eyepopslikeamosquito (Archbishop) on Aug 09, 2005 at 21:22 UTC
Re: Paranoid about web application security
by Anonymous Monk on Aug 10, 2005 at 15:59 UTC
    If you're using Perl for you project, there's no way you qualify for the paranoid label. The truly paranoid would use something like Spark Ada for the implementation language.