Web-based application security is a complex topic, requiring attention at network, hardware, operating system, web server, application and database layers. At the application layer the groundwork class provides mechanisms for controlling access by IP Address, HTTP Referrer and Form Submission Method.

One way to secure part of an application is to deny or allow access to certain IP addresses. Groundwork provides a built-in mechanism for implementing this kind of security.

To restrict access to a particular cgi, you can place lines like the following in a skin variable (.var) file that the cgi will read.

denied-ips = .*
allowed-ips = (10\.[0-254]\.[0-254]\.[0-254]|192.168.[0-254].[0-254])

When the execute() method of the groundwork class runs, it evaluates the allowed() method which in turn evaluates the ipAllowed() method. This method looks for denied-ips and allowed-ips variables in the skin variable (.var) file and treats their values as regular expressions to deny or allow access. The example denies access to all IP addresses then allows access to the 10.0.0.0 and 192.168.0.0 networks. First, denied IP addresses are evaluated, then allowed IP addresses. After evaluating both, if an IP is not allowed, the invalidIp() method is called which in turn calls the invalid() method. This method returns a 403 Forbidden error to the browser.

If you would like IP Security to work differently, you can subclass groundwork and override the execute(), allowed(), ipAllowed(), invalidIp() or invalid() methods. If you don't want IP Security at all, you can leave the allowed-ips and denied-ips variables out of the skin variable (.var) files, leave them in with blank values or override the execute() or allowed() methods to exclude the check.

If you want to prevent bookmarks or links from other sites into your application from working, you can evaluate the HTTP_REFERER environment variable to deny or allow access. Groundwork provides a built-in mechanism for implementing this kind of security.

When a browser requests a URL from a web server, it sends the web server the URL of the referring page. The web server stores this value in the HTTP_REFERER environment variable.

HTTP_REFERER's are notoriously inaccurate. Some browsers don't send them if the referring page was served over https. If the referring page was a non-http URL such as a bookmark, email, or newsgroup posting, the browser may send a referring URL but different browsers send different URLs and in some cases, some browsers send nothing. Command line programs like snarf and wget can send whatever referring URL you tell them to.

Despite it's inaccuracy HTTP_REFERER-based security can be quite successful at deterring unwanted access; but it should not be your only line of defense.

To restrict access to a particular cgi, you can place lines like the following in an skin variable (.var) file that the cgi will read.

denied-referers = .*
allowed-referers = ^http:\/\/www\.firstworks\.com

When the execute() method of the groundwork class runs, it evaluates the allowed() method which in turn evaluates the refererAllowed() method. This method looks for denied-referers and allowed-referers variables in the skin variable (.var) file and treats their values as regular expressions to deny or allow access. The example denies access from all referring pages then allows access to links from referring pages starting with http://www.firstworks.com. First, denied referers are evaluated, then allowed referers. After evaluating both, if a referer is not allowed, the invalidReferer() method is called which in turn calls the invalid() method. This method returns a 403 Forbidden to the browser.

If you would like Referrer Security to work differently, you can subclass groundwork and override the execute(), allowed(), refererAllowed(), invalidReferer() or invalid() methods. If you don't want Referrer Security at all, you can leave the allowed-referers and denied-referers variables out of the skin variable (.var) files, leave them in with blank values or override the execute() or allowed() method to exclude the check.

Requiring that other pages link to a page from forms using the POST method can help secure a page in two ways. First, browsers and proxy servers tend not to cache pages that were linked to from a form using the POST method. And, form variables aren't displayed in the URL when the POST method is used. Potentially sensitive information is hidden in the page source, so if someone is peeping over your shoulder, they can't see it.

To restrict access to a particular cgi, you can place lines like the following in an skin variable (.var) file that the cgi will read.

denied-methods = .*
allowed-methods = POST

When the execute() method of the groundwork class runs, it evaluates the allowed() method which in turn evaluates the methodAllowed() method. This method looks for denied-methods and allowed-methods variables in the skin variable (.var) file and treats their values as regular expressions to deny or allow access. The example denies access from all methods then allows access from pages that use the POST method. First, denied methods are evaluated, then allowed methods. After evaluating both, if a method is not allowed, the invalidMethod() method is called which in turn calls the invalid() method. This method returns a 403 Forbidden to the browser.

If you would like Form Submission Method Security to work differently, you can subclass groundwork and override the execute(), allowed(), methodAllowed(), invalidMethod() or invalid() methods. If you don't want Form Submission Method Security at all, you can leave the allowed-methods and denied-methods variables out of the skin variable (.var) files, leave them in with blank values or override the execute() or allowed() method to exclude the check.