Request a topic or
contact an Arke consultant
All posts tagged 'iis'

Arke Systems Blog

Useful technical and business information straight from Arke.

About the author

Author Name is someone.
E-mail me Send mail

Recent comments




The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2023

Debugging with Visual Studios (SQLite error)

I’ve run into a reoccurring error that only pushes to the surface while debugging.  The following error:

Could not load file or assembly 'System.Data.SQLite, Version=, Culture=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Is a result of IIS and the windows box trying to run 32 vs 64 bit versions of the application and of the sqlLite.dll.  There are two dlls involving sqlLite.  One is System.Data.SQLite, the other System.SQLite.  If you don’t require SQLite in your project, remove it or rename it from a .dll extension.  See post for Web Forms for Marketers on how SQLite might affect you.  If you must use SQLite, it is recommended that you download the correct version of the dll from here: 

**There have been issues with people running the application after downloading the correct 64 version of the dll and running sitecore as a 64 bit application.  Be sure you have .NET SP 1 installed on your VM or other.

Tags: , , , ,
Categories: Sitecore
Posted by Nicole Rodriguez on Monday, April 12, 2010 12:37 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Mitigate SQL Injection Attacks on Legacy ASP Sites

For those of you, like me, that have to support old sites for your clients, dealing with the vulnerabilities of old code can be quite a hassle.  Especially now that the best documented and known exploits can be completely automated.  One of our clients was recently subject to such an attack.  Unfortunately, when the site was originally developed, no real security was built into the code.  One user posted all SQL requests, no matter if it was coming from the public side or the admin side. All requests came directly from the page, meaning that every page had the code, and every one would have to be touched to really fix it.

As we were already redeveloping the modern replacement to the site, the client wanted us to spend as little time as possible on the old one.  So a true security audit was out of the question.  This, of course, is still the right way to solve the problem, but right isn't always in the budget.  So that leads us to a couple tools to help avoid the problem until we could release the replacement site.

The first is a tool from Microsoft called URLScan. URLScan has a lot of features, but what we used it for here was to limit the length of query strings.  Since the attack strings were almost always longer than a regular POST or GET, we just had to limit the length of the strings for most of those attacks to fail. Take a look at it, there's lots of neat tricks URLScan can do.

The big gun we used was an ISAPI filter written by Rodney Viana.  It's designed to scrub GET and POST requests of anything that would look like an attack.  It has been a life saver, especially when the attacks were happening hourly.

Posted by Wayne Walton on Monday, June 16, 2008 10:50 AM
Permalink | Comments (0) | Post RSSRSS comment feed