What's In The Box?

As a programmer who loves most aspects of eCommerce, I’m constantly evaluating different shopping carts (both open, shared, and closed source) to see where I can keep Dallas Shooting Supplies up and running the best.

Originally, Dallas Shooting Supplies was built on an old version of Artisan Cart, my first shopping cart software. It was somewhat limited, but it worked and helped launch my small side business. When we had the site redesigned, I figured it was time to move to a new platform.

I had gotten used to Wordpress and enjoyed it as a publishing system, so when I saw there was an eCommerce plugin for it, Shopp, I was excited. I was reluctant to purchase Shopp at first, but for $55 + $25 for the Authorize.net plugin, I didn’t have much to lose, I thought.

Shopp turned out to be a tremendous disappointment. So much so that when I went to make the site live, it failed entirely. I finally found the bug in their system, patched it, and told them about it. Shopp is horrible. Don’t buy it, don’t use it. The code is deplorable, the database is very poorly set up (do not store serialized data, use proper table normalization instead).

Looking to move away from Shopp, I visited http://www.practicalecommerce.com which gives reviews of eCommerce solutions, and has a directory of shopping cart software to use. Browsing through the directory, I found a cart that seemed very complete.

It was commercial, meaning it wasn’t free, but offered a 60 day trial. I could download the software, use it on my server, and if I wanted to purchase it after 60 days, I could. This is the correct way to do commercial web software that is self hosted. It gives me an opportunity to view the source code to ensure there exists an obvious coding standard, and the code is efficient. Both seemed true. Great, I thought I finally had found an eCommerce solution that wasn’t bloated, had tons of features, and wasn’t Magento or osCommerce.

However, I wanted to perform a security analysis before I was going to re-move all of Dallas Shooting Supplies to a new platform. I did the usual test of a basic XSS (Cross Site Scripting) attack. It appeared the shopping cart was using a home grown framework (which isn’t a bad thing), and that all of the vectors I checked seemed to not be vulnerable. http://ha.ckers.org/xss.html is a great resource to learn about potential XSS vulnerability vectors. Generally, in an eCommerce application, a naive approach to filtering all HTML/CSS/JavaScript is fine.

Next were the Cross Site Request Forgery (CSRF) attack checks. This is where the cart failed, and failed miserably. After logging into the admin panel, I could easily have a form on a separate domain (site) post data to an admin form and have the data saved. For example, I could easily change the administrators username and password, or update all users to have the same password so one could login as them and steal their info. However, being able to manipulate the administrators username and password was obviously the most nefarious use of this vulnerability.

Furthermore, one was able to manipulate data through basic GET requests. I could easily delete a product by calling a URL with the product ID. Scripting this would be trivial, and before they knew it, a site admin would have unknowingly destroyed their entire shopping cart.

The final check was the SQL Injection attack and this software failed miserably on this, but not in the typical sense. The forms were protected from the typical attack of attempting to escape out of the SQL string to execute arbitrary SQL. Again, because the cart was using a homegrown framework, all of the queries were routed through a common DB interface, which handled properly escaping the SQL query.

This cart provides an interface in the admin to backup and restore SQL snapshots of the database. This is great for backups, but horrible for security. The utility will let you download the SQL snapshots, as well as upload them. However, they can be uploaded from a cross domain. For example, you can upload the SQL file from http://example.com/database.sql and execute it. Hopefully, you can see where this is going. Through the CSRF attack, I simply made a SQL file with `DROP DATABASE db_name` as the entire contents. I uploaded this to a separate site and through a form, was able to upload the file to the site with the shopping cart software. Executing it involved another request to the shopping cart software, with the name of the file as a hidden form variable and another hidden form variable to define the action, executing the SQL file.

Of course, its improbable to know the name of the database. However, the names of the tables are generally the same amongst installations, so the SQL file could be extended to simply drop all of the tables in the database (the shopping cart software selects the proper database to begin with).

I’ve alerted the developers of the vulnerabilities, provided them a writeup of how to execute them, and even provided a test environment for them to execute the vulnerabilities. I told them they had 2 weeks to alert their customers and fix the vulnerabilities. After that time, I’ll disclose the name of the shopping cart software along with how to execute the vulnerabilities.

Even the largest of websites are not impervious to vulnerabilities, but it is possible to diminish the chance of a vulnerability affecting your site by following basic security procedures.

Over the weekend, the website I built, www.prospectvista.com suffered some downtime. Going to the website showed a general error because its a live site, and you should not have in-depth error reporting turned on a live site.

Initially, I thought it was the result of accidentally updating the software that powers the site and broke something. I checked the revision in Subversion (and the version according to our versioning system), and everything checked out all right.

Running a simple `free -m` showed there was plenty of memory available, and swap was being used fine, so that wasn’t it.

Next, I restarted apache, figuring something had gone wrong and that would solve it. It didn’t. Apache restarted, but I was getting the same error.

Determining I couldn’t break the site any worse, I turned on error reporting and went to the site. “A valid database connection could not be created.”

Simple, `sudo /etc/init.d/mysql restart`

[fail]

Well, damn.

I then checked the MySQL logs. Nothing. Same with the Apache logs, nothing that could give me a specific idea of what was happening.

However, in addition to the [fail] restarting the MySQL daemon gave me, I also got this error:

“/etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full!”

Ah hah!

Running a `sudo df -h` showed that /dev/sda1/ was 100% full. There are only two areas that a lot of data is stored on the system: the actual site itself that stores the videos and photos, and the backups. The site content itself was pretty small. I went to the local backup directory and there were tons of outdated backups that were no longer needed. Note: I do remote backups for ProspectVista as well.

I deleted about 80% of the outdated backups and the drive usage dropped to 13%.

Perfect.

Now I have a small shell script that checks the disk usage once a day and emails me if it is 80% or above. I suppose I could also update the backup scripts to delete old backups, much like my Amazon S3 Backup Program does.

I’ve read Daniel Miessler’s blog for a while now as its popped up on different sites like Reddit and Hacker News. I never officially subscribed to it in any formal capacity, but yesterday he had an article on using git to manage his site. The article taught me a lot about git, but I was more interested in the footnote of another article he wrote.

[ If it seems like this post is a note to myself, that's because it is. :) That's how the entire site got started, actually. ]

I liked that. For the longest time, I felt like this blog (or my writing online) had to be very long, very drawn out, thought out entries. I think I can safely change that now. It’s my writing online and I want both entries: long very well thought out ones introducing new ideas, and short ones that are simply notes to myself or small snippets of code or ideas.

I like learning something new each day. Today, I learned the basics of git submodules. Similar to Subversion svn:externals, git submodules let you have additional repositories as sub-directories to your main project. I used svn:externals a lot when I did everything with Subversion. Rather than keeping the Artisan System framework installed at, say, /usr/share/artisan-system/, I always like to install it with the project I’m working on. That way, I can create an immediate release with all of the code in a single location. Additionally, if I come across a bug as I’m developing, I can immediately fix it there, commit to the HEAD of Artisan System, and then tag it and push it to GitHub.

If you have a project hosted at GitHub with the clone URL: git@github.com:leftnode/Artisan-System.git and you want to set it as a submodule, git handles this easily.

# Ensure you are at the root of your git project, i.e., where the .git directory is
 
# This makes the directory lib/Artisan/ a submodule repository
git submodule add git@github.com:leftnode/Artisan-System.git lib/Artisan
 
git commit -a -m "Added Artisan System framework as a submodule."
git submodule init

If you make a change to any of the files in the submodule, be sure to commit them first. Then commit the parent project to ensure both are up to date.

# In the submodule directory
cd lib/Artisan/
vim Iterator.php
# hackity hack hack
git commit -a -m "Updated Iterator.php with something or other."
git tag 0.5.2 -m "Creating the 0.5.2 tag with some changes to Iterator.php."
git push origin --tags
cd ../../
git commit -a -m "Updated the Artisan System submodule."
git submodule status

The last output will show you your submodule is at the latest tag.

 07bd774e56d645844d9eb3691cea706a065288ee lib/Artisan (0.5.2)

You can read a much more in depth guide at Fraser Speirs blog.

Subversion, you’ve been great. Awesome I’d say, but its time to move on. I was first introduced to Subversion in 2006 when I started working for New Media Gateway. I had heard of CVS, of course, but never had a Linux server set up to really use it. Plus, on most projects, it was just me working, so I really didn’t need any source control (note: this is not a good thing, you should be using source control even if you’re the only developer on a project).

So I begin working at NMG and they’re using Subversion. It’s just what I used. It seemed to work fine, and since one of the other programmers managed merges and releases, all I had to do was update my working copy and check stuff in. I wrote hook scripts, and everything worked great.

Then, I was introduced to git by Zach, and boy did I love to rip on it. Decentralized version control, but look, you have to centralize it somewhere, like GitHub, right!? One day, GitHub was down and we had a good laugh. But Zach started using it for a new project he was working on.

When I moved to New Legend Media, it was natural that I introduced Subversion as the source control system to the company. It was all I knew, it was stable, and it had very competent Windows tools for designers. Together, with another developer there, we set up a Subversion server and through a few rough patches, we started using it. I became very comfortable with it. I learned branching, and merging, release management, and general sever maintenance. He raved at how well it handled branching, merging, releases, bug fixes, and all of the other features of a DVCS. I scoffed at them, and said I’ll stick with my Subversion. The 1.5 series was stable, had automatic branch management built in for easy merges, and I had all of my code in there.

But in the back of my mind, I knew I needed to learn how to use git, but I was reluctant. I’m not exactly sure why, but I just felt like Subversion was great for me. Eventually, I just broke down and asked Zach to show me git. He guided me through setting up my .gitconfig file so I could have my nice Subversion aliases and colored output, to setting up a GitHub account, and finally how to branch and merge. Git was amazing. So one by one, I started moving all of my projects to my GitHub account.

And thats where I stand today. I’ll always have a soft spot in my heart for Subversion, but for starting a new project, Git just can’t be matched.

cd /path/to/svn/repos/
sudo svnadmin create /path/to/svn/repos/reponame
sudo chown apache:apache reponame -R
sudo chmod 700 reponame -R

vim File.php
# hacky hackity hack
git init
git remote add github git@github.com:leftnode/New-Project.git
git push github master

Goodbye Subversion, it really sounds like goodbye to an old friend, but I’m really excited about git!