Thread

Hello,

I’m planning on building a ecommerce-solution in with CI and I’m trying to figure out, if there’s something I should take care of, security-wise.

And since I’m pretty sure, other-ones would appreciate advice as well and I couldn’t find much in here, I was hoping, someone among you might wanna share some wisdom?

Thanks a lot for every hint.

—trice

Off the top of my head, heres a few things

1) [MOST IMPORTANT!]  Get a good webhost with a reputation for security.  I can’t tell you how many times people report that “my site was hacked” when in actual fact its that their shared hosting allowed another user on the same server to escalate their privileges.
2) Enable global xss filtering
3) rename your system directory, and move it out of a web accessible location
4) stay current with CI
5) use helper functions and libraries.  The input class in particular
6) be paranoid about validation.  If you know its a 3 digit number, don’t just check that something is a number.
7) don’t modify the CodeIgniter core.  Extend, override, but don’t hack.

I made not long ago a small e-commerce website built on CI. It worked fine, the problem isn’t with CI you have to worry about its how you handle the shopping cart. I found while developing there were so many areas people could hi-jack posted form data and possibly change the amount they got billed. So had to use extensive methods to verify form data was what I expected it to be.

But as Derek said, if you use the stuff provided you should be fine.

Edit: I have one question, say you found a small security hole, would you instantly release a new revision of CI or just put it in the SVN till the next update was due.

It would depend on the nature of the hole I guess.  If it was something that we felt would impact all users, we’d probably do an immediate new release.  If it was “if $this and $that are both used, and its Tuesday, and the database is mysql with global variables….” then we’d probably just drop it into the svn.  Obviously, we take security very seriously.

Man, you’re fast—thanks a lot!

@Derek:
1. Do you’ve any experience/advise concerning “good” hosting services?—I’m atm. at BlueHost and they seem quite alright,…
3. Not sure, how to do that (sorry, if that sounds a bit naive…well, it probably is :D )—wouldn’t I’ve get some routing problems then?
But let me guess, this has probably been discussed somewhere in this forum already, right?

@adamp1:
That sounds like a important experience—would it be okay to ask you for an example of what you’re talking about?

I found while developing there were so many areas people could hi-jack posted form data and possibly change the amount they got billed. So had to use extensive methods to verify form data was what I expected it to be.

And another question:
Do you’ve any advise concerning the choice of an authentication-library?—What I mean is:
Freakauth sure looks great, but it seems also quite a lot of work to implement into a ready backend, since many things are already pre-defined. On the other hand erkana or pc_user seem simple enough and provide basically what I’d need (and give me possibility, to quite easily extend the functionality), but are they as “safe” as Freakauth?

Thanks again.
—trice

// EDIT:
And I almost forgot: Do you’ve any (bad) experience with SSL and CI?

ErkanaAuth is as safe as you make it. Authentication comes down to nothing more than: “is there a row in the database with this information?” ErkanaAuth just makes it a tad-bit easier to do that. It is still up to you to make it secure.

For authentication, I do something like this:
1. User registers with email/password
2. Encrypt the user’s password
3. Generate a 7 character salt
4. SHA1 the concatenation of the user’s encrypted password and their salt

For form validation (to prevent cross-site forgeries):
1. Generate a 7 character random string, encrypt and store in a session for that user
2. Place a hidden field on the form with that 7-digit random string
3. Upon submission, ensure the POST matches the session

For hijacking the data and changing how much they should be charged - I can’t think of a situation where this “should” be possible. The form the user submits should only tell the backend which item they want - nothing to do with the price.

There would then be a table to store active carts, with item and price information. The only way this can be changed is by the user submitting a form that alters the quantity of an item (or maybe a coupon code, or something). When the user clicks checkout, the back-end pulls all of the pricing information from the active cart record and proceeds with payment.

Doing it this way will also keep administrators from accidently altering prices on an active cart. If I have 3 items at $5.99 in my cart and I am still browsing around the site when an admin lowers/raises the price, my cart will still remain at the same price (and not change to the currently active price on the site).

Thanks again—this is all really valuable information for me and I would almost have a bad conscience to ask for so many details, if I wouldn’t have seen, how many people encounter similar problems.

One question,  though:

1. Generate a 7 character random string, encrypt and store in a session for that user

—At what point do you create this string? On log-in?

So,—any more advice anyone?

—trice

Not necessarily on login - it could be for any form. This simply provides protection that when a form is submitted to your site, it actually came from your site and that you are expecting this form to be submitted.

A workflow similar to this:
1. User visits site
2. User clicks on “Post Message” button
3. Validation determines this form has not been submitted - let’s display a form to the user
4. Controller generates a 7-char random string, stores it in a session, and passes it to the view
5. This string is placed within a hidden field on the “Post Message” form - right next to message body and title.
6. The user presses the submit button, the same controller is loaded again
7. Validation determines this form has been submitted - let’s make sure it validates
8. Session string and the hidden string match, move on to other rules
9. Body and title are there (they were required) - this form looks good, send to the model to insert into the DB
10. Redirect the user somewhere (maybe to view the message they just posted)

You see - if that form was submitted to my controller, from a different domain or without first loading the form and submitted that form - it would fail out on step 8.

Thanks, now I got it!
Sounds like a smart way to a handle this. I’ll definitely give this a try.
—trice

Basically I had to do what Michael said, but I did find when submitting data to paypal that it could be changed and very hard to verify. Since before I sent them to paypal I stored the order in the system. They paid and then it confirmed it was a valid order. BUT they could change the amount needed to be paid, and paypal wouldn’t know. So I think what I did was encrypt the price using SHA-1 and a salt and pass this as the custom field to PayPal. Of course paypal when verifying the transaction would pass me back the amount transferred and the encryption. I would just make a new hash of the price I have stored in the system and compare the values. (Of course the user can’t hijack this data since it doesn’t go through their browser)

Don’t know if there is a better way. I know other shopping carts send you back a hash of the whole shopping cart you upload to them.

Two biggest mistakes I see made by developers:

1) Not proofing your queries against SQL Injection. If you use CI’s Active Record, PHP’s PDO, etc., then this is less of a concern. But make sure you’re doing something at least.

2) When passing around record ID’s in the query string, not checking to make sure they are a) valid (that record exists), and b) the record belongs to the user requesting it, or the user has permission to view that record.