http://www.dind.com/blog/security/ en-us Fri, 18 May 2012 19:58:13 PDT Fri, 18 May 2012 19:58:13 PDT SiteCrafting.com GearBox 1.1 (beta) http://www.sitecrafting.com/blog/master-domain/ It begins with a letter or maybe even an "invoice". It ends with the transfer of your domain to another registrar and in some cases even the loss of your domain entirely.  The term for this is Domain Slamming.The practice preys upon unsuspecting people who want to pay their bills and keep their domain names current. After all, we have our domain name printed on every invoice, business cards, painted on our trucks, and we advertise with Google Adwords, we don't want our domain to expire. This is exactly what they count on.  We at SiteCrafting have noticed a growing number of domains that are either being hijacked by these scam artists or are trying to be hijacked. So what can you do?Investigate the source of the letter or invoice, a quick Google search on Domain Registry of America will highlight it as a scam.Check your domain status - Free tools like www.allwhois.com can give you your domain information and more importantly expiration information.  If we host your domain or provide registration services for you, know that we automatically renew your domains for you each year to insure they are renewed.If you have paid one of these companies or agreed to a transfer your domain, you can file a complaint with your state's attorney general office and the FTC. SiteCrafting is committed to providing our customers transparent service when it comes to domain hosting, web development, and regsitration services. If you ever have any questions on the process please don't hesitate to contact us. As an added precaution, SiteCrafting has enabled Registrar-Lock on all domains to insure that they must be unlocked prior to transfer.  This addition saved one of our valued clients from losing nine domains to Domain Registry of America this morning.Related Links:http://www.ftc.gov/opa/2003/12/domainreg.htmhttp://www.domainavenue.com/scam_domain_registry_of_america.htmhttp://www.theregister.co.uk/2004/01/06/court_bars_canadian_domain_slammer/http://support.easydns.com/domain.slammers/droa.php Wed, 15 Nov 2006 21:12:00 PST http://www.sitecrafting.com/blog/facebook-beacon-social-media-spyware/ I've been a Facebook user for quite some time - even before they had the facebook.com domain. One thing that I absolutely love about it is the control they give you to limit what other people see about you. I've adopted a very serious set of controlls that limits only people I actually know to see anything about me. However, this is a false sense of security. Everything I post online that anyone besides me can access is inherently public. This is what initially drew myself and countless other people to Facebook.However, their new advertising platform - Beacon - throws all this out the window. Beacon is a system that allows Facebook to track what you do on other websites. Let me reiterate that: Facebook tracks what you do online. They don't just track what you say you like on your profile, for example what movies you like; with Beacon they can track what movies you're actually renting. This is a marketer's dream come true. Facebook has millions of users, all happily entering what movies they like, what books they read, what they like to do, and what music they listen to. From there, it's trivial to create user profiles. They can determine that 35% of white males between 18 and 25 like to listen to Led Zeppelin. I just made those figures up, however I can see that more people like Jack Johnson than Coldplay in my college network. Putting numbers on that would be simple for Facebook. So Facebook has all this data, but what are they going to do with it? If you're thinking, "sell it", you're probably right. They are sitting on a gold mine of information. Anyone with an interest in data mining would be cackling with glee if they got their hands on that info. This all leads to better profiling and better marketing schemes with the ultimate goal of getting you to buy more stuff you don't need. Coming back to Beacon, they are now able to track what you do on just about any site on the internet. They can see what you buy, what you rent, what games you play, and if you're getting your girlfriend an engagement ring. Even though Facebook recently changed Beacon's reporting mechanism on their site (you now have to actively approve stories for them to show up), they are still collecting that data. It just isn't published. The conclusion that follows is somewhat disturbing: Facebook may be great at making an adversiting platform, but they're not so great when it comes to their user's privacy. Their concern is obvious: to serve the needs of advertisers while paying lip service to "what the users want" - information about what their friends are doing. They're assuming that their ends of providing good advertising justifies the means where they invade the user's privacy to a degree not seen before on the internet. And as I learned from philosophy, the result of your actions does not justify any unethical decisions you had to make to get there.That's why I'm blocking Beacon, removing all my interests and likes from the site, and most other personal information I put up there. I don't like people snooping into my information, and I won't make it easy for them. They probably have a profile on that, too. Tue, 04 Dec 2007 11:41:00 PST http://www.sitecrafting.com/blog/php-passes-homeland-security/ When meeting with prospective new clients, we tell them that SiteCrafting uses PHP and MySQL as the development platform. Invariably this leads some of them to ask us what PHP and MySQL are and if they are safe and fast. Sometimes, this can lead to interesting conversations, where we explain to them why we think PHP and MySQL are safe and fast. Occasionally, there's a client who remembers reading an article 4 or 5 years ago about PHP 3 having some security issues. We refer them to current articles on PHP and mention our own experiences, but the latter argument can come across as "Because we say so," which isn't a good way to get the point across.Fortunately, with a recent announcement that 11 open-source projects, including PHP, Perl, and Python, passed the current highest "Rung" security testing for Homeland Security, we have some more ammo to support PHP's security. This security rating will help instill some confidence in our clients in choosing PHP and thus, SiteCrafting. Wed, 09 Jan 2008 15:51:00 PST http://www.sitecrafting.com/blog/quick-lost-content-recovery-option/ No matter how protected your website may be, sometimes you still need a helping hand when an accident happens. Delete a page while fumbling with FTP? Someone else in your office write over your work on a webpage? Heck, maybe your entire site is down! Google Cache may be able to help. Even with offerings like distributed server environments, backups, content versioning, etc. that we're proud to offer clients here at SiteCrafting, sometimes a quick, self-serve fix can be just the answer. Enter Google cache. Most webpages that Google indexes are stored temporarily to allow searchers options for viewing content results. This feature can also be used to recover written content (not images and other rich media) in a bind. Here's what you do:Enter the web URL of the page you want to recover into Google's search boxorSearch for some content on the afflicted page in quotes with the domain name after it (e.g. "brief timeline" sitecrafting.com)Click on the "Cached" link when find the right result pageCopy and Paste and re-format the content into your webpage editor to save and re-post on your siteI've recommended this method a few times to folks that haven't thought of Google's cached pages in this way. Your mileage may vary, of course, depending on how often Google crawls your website and how long it's been since your content r-u-n-n-o-f-t. In the meantime, happy cache spelunking! Mon, 18 Aug 2008 14:48:00 PDT http://www.sitecrafting.com/blog/mysql-login-truncation/ Stefan over at Suspekt brought up some interesting security vulnerabilities based on MySQL's column truncation tendencies (when not in strict mode), so I thought I'd add my own to the pile, this one right in the grant tables.MySQL's user table restricts user names to 16 characters (and hosts to 60). Any attempt to create a user with a longer login results in an error. However, unlike Stefan's example where a field is compared, then truncated and then inserted, MySQL actually truncates a login attempt before processing it.First, just to confirm that longer usernames are not permitted:mysql> GRANT ALL PRIVILEGES ON test.* TO 'toomanycharacters'@'localhost' -> IDENTIFIED BY 'pass';ERROR 1145 (42000): The host or user argument to GRANT is too longNext we create a user with the maximum length:mysql> GRANT ALL PRIVILEGES ON test.* TO 'sixteencharacter'@'localhost' -> IDENTIFIED BY 'pass';Query OK, 0 rows affected (0.00 sec)Test the login the way it ought to go:$ mysql -u sixteencharacter -ppassWelcome to the MySQL monitor.  Commands end with ; or g.Your MySQL connection id is 34510 to server version: 5.0.22-standardAnd finally, log in with a too-long username, matching on the first sixteen characters:$ mysql -u sixteencharacterASDF -ppassWelcome to the MySQL monitor.  Commands end with ; or g.Your MySQL connection id is 34517 to server version: 5.0.22-standardWait, what?There is no user in the system called 'sixteencharacterASDF'...mysql> SELECT User, Host FROM user WHERE User = 'sixteencharacterASDF';Empty set (0.00 sec)...which means that the login process, instead of rejecting what is fundamentally an invalid account, says "well, that's too long, so we'll assume they meant just the first sixteen characters."Now, granted you have to get the first sixteen characters right in the first places, so it doesn't make it any easier for a hacker to guess. But I am still of the opinion that if the username is wrong, the user shouldn't be allowed in.It also brings up an interesting question (which I don't have the resources to test at the moment): does the same truncation happen on a host name? could 'test'@'subdomain-that-is-way-too-long-too-be-useful.sitecrafting.com' access a database restricted to 'test'@'subdomain-that-is-way-too-long-too-be-useful.sitecrafting.co'? Another argument for restricting your user access by IP rather than domain, I suppose. Wed, 20 Aug 2008 11:20:00 PDT http://www.sitecrafting.com/blog/subversion-checkouts-live-webapps-be/ The web design and development blog Smashing Magazine published an article today about a problem when using a Subversion checkout to deploy files to a live webserver. In short, anyone could browse to a directory on your website, and see all the source code, including database connection information. (Don't worry, at SiteCrafting we don't do this. We have a much better system.)The Smashing Magazine article includes tips on how to secure common web servers. Here's another way to secure a site using two simple htaccess rules. Securing your site using htaccess is very easy, you just need to add these simple rules to the .htaccess file in your root directory:Options -IndexesRewriteEngine onRewriteRule (.*)\.svn/(.*) - [F]This tells Apache to display a 403 forbidden message when trying to access a directory listing (if an appropriate index.html or index.php doesn't exist), or anytime someone tries to view any file under any .svn directory. (You really only need the Rewrite rules, but Options -Indexes is useful as well.)Checkouts are really not intended to be used on a live web application. It's much more appropriate to use an export, because you shouldn't need to check in any files on a live site. However, it's incredibly useful to be able to update a live project to the most current version by only updating the recently changed files.[dave@banana live-website]$ svn upU    index.phpU    about.phpA    images/picture-of-dave.pngUpdated to revision 93.Wordpress, for example, uses checkout very effectively. Smart Wordpress developers will install a WP instance with $ svn co http://core.svn.wordpress.org/tags/2.8.4 .Later, when a new version is released, developers can then upgrade by doing something like this: $ svn sw http://core.svn.wordpress.org/tags/2.8.5/ . Considering how fast and often Wordpress gets hacked, it's a great idea to have the ability to instantly upgrade to the latest version.The bottom line is that developers should be aware of the perils of using a SVN checkout. If they still chose to do it, they should take the proper steps to make sure their applications and their clients' data is not compromised. Fri, 25 Sep 2009 10:21:00 PDT