Most merchant Web servers are contacted by completely unknown, often even anonymous, users. Thus they cannot generally protect themselves by demanding client authentication, but rather by employing carefully configured access control mechanisms. These range from firewall mechanisms and operating system security to secured execution environments for mobile code. Generally, all types of mechanisms that allow a client to execute a command on the server should be either completely disabled or provided only to a limited extent. Denial-of-service attacks on Web servers have much more serious consequences for Web servers than for Web clients because for servers, losing availability means losing revenue. Web publishing issues include anonymous publishing and copyright protection. Web servers must take special care to protect their most valuable asset. Information. which is usually stored in databases and in some cases requires copyright protection.
TopWeb Server Security Issues
When you run a web server, you are allowing anybody who can reach your machine to send commands to it (Zwicky, et.al, 2000). If the web server is configured to provide only HTML files, the commands it will obey are quite limited. However, they may still be more than you would expect; for instance, many people assume that people cannot see files unless there are explicit links to them, which is generally false. You should assume that if the web server program is capable of reading a file, it is capable of providing that file to a remote user. Files that should not be public should at least be protected by file permissions, and should, if possible, be placed outside of the web server's accessible area (preferably by moving them off the machine altogether).
Other web servers, however, provide services beyond merely handing out HTML files. For instance, many of them come with administrative servers, allowing you to reconfigure the server itself from a web browser. If you can configure the server from a web browser, so can anybody else who can reach it; be sure to do the initial configuration in a trusted environment.
Web servers can also call external programs in a variety of ways. You can get external programs from vendors, either as programs that will run separately or as plug-ins that will run as part of the web server, and you can write your own programs in a variety of different languages and using a variety of different tools. These programs are relatively easy to write but very difficult to secure, because they can receive arbitrary commands from external people. You should treat all programs run from the web server, no matter who wrote them or what they're called, with the same caution you would treat a new server of any kind. The web server does not provide any significant protection to these programs. A large number of third-party server extensions originally ship with security flaws, generally caused by the assumption that input to them is always going to come from well-behaved forms. This is not a safe assumption; there is no guarantee that people are going to use your forms and your web pages to access your web server. They can send any data they like to it.
A number of software (and hardware) products are now appearing with embedded web servers that provide a convenient graphical configuration interface. These products should be carefully configured if they are running on systems that can be accessed by outsiders. In general, their default configurations are insecure.
Besides these issues, the server provides a number of optional features, that are not secure. These features are (http://www.w3.org/Security/Faq/wwwsf3.html). These features are: