As already mentioned by someone who posted as Anonymous Monk, merlyn wrote an article, along with an example script (like always), on the best (and only) way cookies should be used (if they need to be used at all). Here's the article, which contains good advice and suggestions. Obey what you read here :)

That being said, definitely don't trust anything you get from the client. The cookie should only indicate which browser (notice the word 'browser', not 'user', since the same user should be able to have multiple sessions open with your web applications) is accessing the script. All data should be contained within a database, including prices (do NOT put prices in hidden html fields), all contact info, and anything else you can possibly think of. Also, make sure you expire the session from the database after a reasonable amount of inactivity. What is 'reasonable' is up to you, but don't leave inactive sessions around for too long, unless you want these picked up by somebody other than the original session creater :)

More from a view of making things work the way you expect, rather than security (but security can always hold a place in these things), is making sure the data you are being forced to receive from the client is the data you are expecting. What if a user tells your script they want 0.5 pairs of shoes? Your script had better insure that the only data it is accepting for quantities is a whole integer: no alpha characters, no decimal, etc etc. If you don't, your web app will charge your shopper the price of one shoe rather than the pair of them. And are you willing to ship out one shoe? :) Even worse, what do you do when someone tells your app "I want to purchase -10 pairs of shoes."? Will your app reject this value or will you be offering a refund for the amount of 10 pairs of shoes?

Are there any non-obvious security-related tips (i.e. besides "use taint checks well" and "encrypt credit card numbers" ...
Um... encrypting credit card numbers? No. Just don't do it. Don't even save the shopper's credit card number in your database, I don't care how safe you think you've encrypted it. If you can decrypt it to the true credit card number, then so can someone else who might find their way into your database. Will this require shoppers to re-enter their credit card number every time they buy something? Yes. Will it make them feel more secure? Perhaps. Will it make you feel better and more responsible when you find out your database has been hacked into by someone else? Definitely! 

-------------------------------------
eval reverse@{[lreP
=>q{ tsuJ\{qq},' rehtonA'
,q{\}rekcaH },' tnirp']}[1+1+
1,1-1,1+1,1*1,(1+1)*(1+1)];
-------------------------------------

In reply to Re: Any tips on writing a shopping cart? by mt2k
in thread Any tips on writing a shopping cart? by BrentDax

Title:
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, details, 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, summary, 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.