Northwind Traders Sample

How It Works

Busy Bee
This page is still being written, and there is much more to document. Try the About and Help pages for further information.

Configuration Settings

The basic configuration file for any ASP.NET web site is the web.config file. You cannot access this file directly because it is a system file with sensitive information in it. The web.config file you can see here is a slightly changed one: only the connection string has been changed to protect the SQL location, user name and password.

<connectionStrings>
<clear />
<add name="Mustang_91989ConnectionString" connectionString="Data Source=ACER\SQLEXPRESS;Initial Catalog=Sample;Persist Security Info=True;User ID=sa;Password=******" providerName="System.Data.SqlClient" />
</connectionStrings>
The syntax is, however, correct. I have used this string on my development machine to access the data locally.

The Site.master file

At the top this page there is a line of text that reads:

<%@ Page Language="VB" MasterPageFile="~/Site.master" CodeFile="howitworks.aspx.vb" Inherits="List" %>
This line changes to reference the relevant underlying .aspx.vb code. The Site.master file provides a "container" (or master page) in which the page contents can be placed. Typically on this site it includes the title, logo and menu system at the top, and the Google Adsense and Google Analytics code at the bottom. The file is also protected, so the link points to a text copy instead. There is also a Site.master.vb file, withe cookie and user rights code in it (see below).

Since almost every page (except the error page) uses Site.master, the menu system and/or Cascading Style Sheet references can be changed on every page by changing one file. This is convenient and saves time for the webmaster.

The ASPX page code

Most pages have VB.NET code associated with them, such as "howitworks.aspx.vb". Typically, each page has a "Page_Load" event, where the programmer can run code to modify the page as it opens, or set up variables, etc. This code runs as the page is being sent to the user's browser.

Next, the IIS server processes the code and ASPX elements in site.master, followed by the code and elements in the actual page being requested. The result of these activities is the HTML and Javascript code in your browser.

On the data pages a few more activities occur. The ASPxGridView control loads the requested data and displays it as requested by the developer. The control is interactive, and uses postback commands to do further actions, and allow the user to view, add, change or delete data, depending on what s/he is allowed to do.

Some Text Manipulation Libraries

The VB code behind pages uses some functions I have written to massage the text. The functions are in a class clsTxt and they are typically used to remove junk (or hacking attempts) from data supplied by the user. "SQL Injection attempts", for example, try to insert SQL commands into data. For this reason characters like the quote mark and the equals sign are stripped out, making this kind of attack much more difficult. Here is a code snippet to illustrate the point:

Dim strValue as string, intValue as integer, oTxt As New clsText
   strValue = Request.QueryString("CategoryId") ' Long
   strValue = oTxt.strLong(strValue)
   intValue = val(strValue)
If the page URL is something like ../Categories/default.aspx?CategoryId=5 then without any error checking "CategoryId" would have a value of 5, but if the hacker tried to be nasty and change it to ../Categories/default.aspx?CategoryId=5;DROP TABLE Category;, then using the strLong function will eliminate all the text and punctuation, and still return the 5.

Another effort, say ../Categories/default.aspx?CategoryId=-212-555-6789; will return a sensible result, even if the supplied value is nonsense.

Other functions can be used to format the next, such as the xChangeCase function, which can format names and bad typing. An example would be "Koos van der Merwe" from xChangeCase("KOOS VAN DER MERWE","N"). This is used for the login registration process.

A final example is the blnYN function, which tries to return a true or false result. If "True", "Yes" or "1" is supplied, then the result is True. All other values return false.

Cookie code

The text manipulation library has two pairs of text functions that help with the data stored in cookies. Only two strings are stored: the user's name, and the user's editing rights. The user name is hidden as a hex string, using xHexString and xDeHexString to store and retrieve this data. The user's editing rights are stored using the xHide and xUnHide functions. Basically these functions work similar to the Hex strings, except that instead of using normal Hex letter pairs like A0 and A1, this function maps them to randomly generated letter pairs, such as "Ts" and "D8".

This makes it difficult for the casual hacker to modify the cookie contents to get more rights. The only easy way to impersonate another user is to gain access to their machine within 20 hours of them last using the web site. If the user logs off then this doesn't help them either, because the cookie exiry date is set back 6 hours and the cookie is deleted. Simple precautions and a good password are the best methods of ensuring your user account is not hijacked. There is just too much effort involved in creating a false cookie with additional editing rights, since registration is usually free anyway.

When the user goes to a page, the Site.master.vb code does the following:

Partial Class Site
    Inherits System.Web.UI.MasterPage
    Private oTxt As New clsText

    Protected Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Init
        '// Get/Set cookies and session values if they have expired
        '   08-Oct-2009 23:14
        Dim strValue As String
        strValue = Session("UserName")
        If Len(strValue) >= 8 Then ' strValue
            '// This is a valid user name
            Response.Cookies("user")("UserName") = oTxt.xHexString(Session("UserName"))
            Response.Cookies("user")("Password") = oTxt.xHide(Session("Editing_Rights"))
            Response.Cookies("user").Expires = DateTime.Now.AddHours(20)
        Else ' strValue
            '// Not valid name. Try to find a cookie
            If Not Request.Cookies("user") Is Nothing Then ' Nothing
                '// Found cookie
                strValue = Request.Cookies("user")("UserName")
                strValue = oTxt.xDeHexString(strValue)
                If Len(strValue) >= 8 Then
                    '// Found cookie's user name
                    Session("UserName") = strValue
                    '// Get the obfuscated user rights posing as a password
                    strValue = Request.Cookies("user")("Password")
                    strValue = oTxt.xUnHide(strValue)
                    Session("Editing_Rights") = strValue
                End If
            End If ' Nothing
        End If ' strValue
    End Sub
End Class
It is important that this code runs before the page begins to load, because the response.cookie function doesn't work correctly once the HTML code is sent to the browser. The cookie stuff needs to go first. The Site.master.vb file also contains some user rights code that is not listed above.

The logout page code is even simpler:

    Response.Cookies("user")("UserName") = ""
    Response.Cookies("user")("Password") = ""
    Response.Cookies("user").Expires = DateTime.Now.AddHours(-6)
    Session("Editing_Rights") = "VZ"
    Session("UserName") = ""
    Response.Redirect("/")

Security Considerations

The site has little or no security, other than password protection provided by the hosting company. There is no security certificate, and therefore no https support, and therefore all passwords are sent by the browser to the server on an open http connection, which is subject to "man in the middle" attacks and packet sniffing. The cookies are also sent to and from the browser "in the clear", except that a small amount of "encryption/obfuscation" is used to make it more difficult to modify the cookie contents. A dedicated hacker might be able to find out or impersonate a user with editing rights. A security certificate may be added later.

I have gone to considerable lengths to ensure that the code and the database cannot be compromised without a hacker obtaining the administrative user name and password, either for the hosting site or the database server. I have also taken additional precautions to prevent "SQL Injection" attacks. Unless there are unpatched flaws in the server software, and the webmaster takes care not to leave "old" copies of pages on the server, the site will not be hacked or vandalised.


Busy Bee
This page is still under development. Apologies for the inconvenience



Advertisement

Advertisement