Server Security

	Server Security

Server Security Model

Each URL request goes through two main phases. The first phase performs access control, and the second phase generates the page.

File-based Access Control
Securing Custom URLs
Access Control Hook API

.htaccess and .tclaccess Access Control Files

Your application (i.e., web site) registers one or more access control hooks with Url_AccessInstall. By default, the server registers the DocAccessControl procedure, which implements access control based on both .htaccess and .tclaccess control files that you can put in any directory in your web site.

There are several examples of access control files. There is also a simple editor for .htaccess files. You must access /htaccess using a "locahost" URL.

Security and Custom URLs

A custom URL is something implemented by pure code in your application as opposed to being based on a document in a filesystem directory somewhere. URL domains are created with Url_PrefixInstall, and Application Direct URLs are a simple kind of custom URL domain you can easily experiment with. For example, the /debug and /status are Application Direct URLs implemented by code inside the basic server that provide simple debugging tools and status reporting.

Some admins may worry about the debug hooks, although I've used them without incident. Through a simple trick, you can use .htaccess or .tclaccess files to control access to custom URL domains. Access control to the "/debug" URL domains is set by the .htaccess or .tclaccess file in the "/debug" subdirectory of your document root. This works because the DocAccessHook always looks in directories for these control files, ignoring the custom URL prefixes.

Verify this by checking this /debug URL which, if allowed, will dump out the contents of the Doc variable. If you are prompted for a login, use the "debug" user and the password printed out when the server starts up.

Now practice modifying the /debug/.tclaccess file to implement a different password checker for the /debug URL.

Access Control Hook Interface

Suppose you register your own access control hook, like this:

Url_AccessInstall MyAccessHook
proc MyAccessHook {sock url} {
  # return either:
  # "ok" means access is allowed
  # "denied" if access is denied
  # "skip" if this hook doesn't have any opinion on the matter
}

Most access hooks do some pattern matching on the url to limit the scope of their checks, such as:

if {![regexp {^(/debug|/status)} $url]} {
  return "skip"
}

There is also Url_AccessInstallPrepend and Url_AccessUnInstall if you want to manipulate the access control hook order. The hook list is stored in $Url(accessHooks). The access control procedures configured for this server:

DocAccessHook
RedirectAccess

Useful Connection State

data(proto) GET

data(url) /learn/security.tml

data(uri) /learn/security.tml

data(prefix) /

data(suffix) learn/security.tml

data(pathlist) learn security.tml

data(self) http standard.prd.co.uk 80

data(mime,host) standard.prd.co.uk

data(ipaddr) 3.147.65.65

You may also want to look at connection state. There is a standard idiom to get this from the $sock variable.

upvar #0 Httpd$sock data

After this, the data variable is an array with various interesting bits of state. The table at left shows several (but not all) elements of the socket state. The $data(ipaddr) value is the IP address of the requesting client. One useful filter is to limit this to 127.0.0.1 so the browser has to run on the same host as the server.

if {$data(ipaddr) == "127.0.0.1"} {
  return "ok"
}

Beware that $data(pathlist) is a side effect of DocAccessHook, which sets this by calling Url_PathCheck to ensure that the URL doesn't use "../" components to sneak out of the URL namespace.

Home Status Learn CGI Tests Templates Access Control Reference Manual


Home	Status	Learn	CGI Tests	Templates	Access Control	Reference Manual