Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
This won't be a terribly long meditation. But it is an important one.

I was bothered by Re: Re: (OT) SSL Certificates: Self-Signing and Alternative Solutions because it shows a fundamental misunderstanding of how easy it is to steal credit card databases. And Re: Perlmonk's "best pratices" in the real world bothered me more because someone came out and said openly that if you haven't used placeholders it is probably because you didn't need them yet. (For those who don't know what placeholders are, DBI lets you just put ? in your SQL, bind inputs to the query, and then the driver takes care of sending data to the database.)

These are both dangerously wrong, and they are wrong for connected reasons. Furthermore the responsibility for their being wrong rests squarely on developers' shoulders. Nobody may have told you that it matters, but it does.

I won't go through all of the details because I don't want this to be a HOWTO Steal Credit Cards guide. But the problem is what is known as an SQL injection attack. You have code that interpolates form data directly into the string. The cracker submits form data that closes off the quoted field, ends the query, and adds another query. The other query can do virtually anything. Depending on the database it can give the cracker a remote login, can determine the schema, can return all credit cards you have, can drop tables, etc.

Finding these is easy. Just walk through some complex forms and enter ' or " into each field until you find one that causes a crash. After that escalate the initial hole into better and better exploits using standard procedures that good crackers are very familiar with. When you are bored with that victim, seek another.

What is more, having the database securely locked behind a firewall won't help - anyone who can reach the poorly coded web page can nail the database. You also can't depend on there being any trouble in figuring out passwords. The attacker doesn't need to know passwords and accounts - you are handing them the login to wreak havoc with. OK, a good DBA can lock things down to limit how much damage having a completely compromised account can cause. But the odds that it has been done with yours are slim to none.

So, what can a developer do about this?

  1. Don't trust user input. Ever. Be paranoid. Using placeholders does this. Escaping things yourself is better than nothing, but by and large the ones who know how to do it right also know enough reasons to use placeholders that they do that instead.
  2. Don't leave debugging hooks like CGI::Carp in production code. The availability of detailed error messages takes virtually all of the guesswork away from the cracker and makes their lives easy.
  3. Upgrade to a recent version of DBI, turn on perlsec, and set TaintIn mode on.
  4. Submit your code to code reviews.
  5. Do a security review. (This is hardly the only common basic security mistake that developers make which nobody else can really do much about.)

There is little that I can do to comfort users about the seriousness of this problem. My guess is that most of us have had our credit cards stolen already, likely multiple times. Few of us would have any reason to know it though. Credit cards are readily available on the black market in bulk (premium prices if they have been tested for validity). Our main protection is that there are too many potential victims and too few crooks.

UPDATE: Fix the link on tainting and fixed a typo (both caught by BazB).

UPDATE 2: Added explanation of placeholders per comment by AM below.

In reply to Use placeholders. For SECURITY! by tilly

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others studying the Monastery: (3)
    As of 2018-05-25 03:39 GMT
    Find Nodes?
      Voting Booth?