- Site Valet Web Components
- Report Component
- Analysis Component
- Administration Component
- Publisher Component
- Security Considerations
- Securing the Network
- Securing the Webserver
- Securing the Database
- Securing Passwords
Site Valet Web Components
The Site Valet Web Components serve two purposes. Firstly they duplicate functions of the Valet Client. Secondly, it extends the Clients capabilities: the Publisher component implements the Publish option in the accessibility evaluation window, while the Analysis Component provides tools independent of the database and alternative report formats.
The Web Components are based on WebÞing's extensions to the Apache 2.0 Webserver. With some modest limitations and loss of performance they can also be supplied as pure CGI for other servers.
The Report Component serves to query and browse the database. The Client windows this replicates are browse, sitemap, validity query, accessibility query, links query and metadata query. This component is particularly useful if you wish to make user-level database functions available to users throughout, and maybe also beyond, your network.
Note that if you make this available over the public Internet, you may wish to protect the server more securely than with basic passwords. Digest Authentication protects passwords more securely but is still open to dictionary attack, while restricting access to SSL offers high security at the expense of a significant performance hit.
The Analysis Component provides interactive analysis functions based on the webserver. These are basically the online Page Valet, Accessibility Valet, Link Valet and cg-eye tools. These have no major security implications, except that if they are accessed by the same username/password as a more secure component then the password must be secured accordingly.
These tools always access pages in real time, without reference to the database. In doing so it complements the functions not only of the Report Component, but also of the Valet Client.
This should be treated as a secure operation. If access is available over the public Internet, it should be secured using SSL. Furthermore, it may be advisable not to enable access to this using the same username/password that access a less secure component.
The Publisher component implements functions to generate new documents on the server by file upload from the Client, and record them in the Valet database. This is for reports that should offer a permanent record, or which are generated under human supervision and so cannot be automatically reproduced from the database, including accessibility evaluation reports.
Security implications of this are intermediate, below that of the Administration Component. In comparison to the Report Component, it is more sensitive in that an intruder could disrupt your system by introducing bogus reports, but less sensitive in that it doesn't expose information about your system.
The Web Components give you only a low level of security: a username/password combination that will avoid casual or accidental problems but is little use against a determined intruder. Where security is a concern, it is up to you to secure the server as you would for any other application running on Apache.
What level of security is appropriate depends on your individual circumstances, but broadly speaking there are three considerations:
- Is anything in the database considered confidential in its own right? QA data for your information systems is unlikely to be your most sensitive data, but it could be useful to an intruder searching for more sensitive information.
- Which components are you running, and what is the level of damage that could be done if someone breaks in?
- Is access to the system required from outside your private network - for example to enable staff to work from home?
Securing the Network
If access to your Valet is controlled by keeping it on an intranet with access restricted to trusted users by firewall and IP restrictions, other security measures may be irrelevant. Note that complete isolation of the valet daemon is not possible, as it needs at least HTTP access to the outside world to check external links.
Securing the Webserver
The single most effective security measure you can take is to secure access to the Webserver itself. Firstly, you may limit the range of IP addresses that can access it in the first place. Secondly, and most importantly, where access might be coming from an untrusted source (particularly over the public Internet), sensitive operations should be limited to SSL (using https: access to the server, as in e-commerce operations).
Note that SSL imposes a substantial load on the server, so using it for everything is expensive.
Securing the Database
If the database server is also used for other applications, it should be secured by the database's protection mechanisms. Passwords available for Web access should have no privileges on any database other than Valet.
Security can be further enhanced by separation of roles. In particular, properly separating high-security administrative functions from user-level functions can serve to protect the former from casual exposure.