HTTP Security Holes
The HTTP protocol has some more security holes to justify a firewall. One of them is that it allows remote users to request communication to a remote server machine, and to execute commands remotely. This security hole compromises the Web server and the client in many ways, including but not being limited to:
- Arbitrary authentication of remote requests.
- Arbitrary authentication of Web servers.
- Breach of privacy of request and responses.
- Abuse of server features and resources.
- Abuse of servers by exploiting its bugs and security holes.
- Abuse of log information (extraction of IP addresses, domain names, file names, etc.)
Most of these security holes are well known. Some applications like Netscape's SSL and NCSA's S-HTTP try to address the issue, but only partially.
Web servers are very vulnerable to client's behavior over the Internet. Therefore, clients should prompt a user before allowing HTTP access to reserved ports other than the port reserved for it. Otherwise, these could cause the user to unadvertedly cause a transaction to occur in a different and danger protocol.
You must be careful also with the GET and HEAD methods! The so trivial link to click an anchor to subscribe or reply to a service can trigger an applet to run without the user's knowledge, which enables the abuse by malicious users.
Another security hole of HTTP has to do with server logs. Usually, a Web server logs a large amount of personal data about information requested by different users. Evidently, this information should remain confidential. HTTP allows the information to be retrieved without any access permission scheme.
Many other HTTP limitations and security holes exist if we were to break down the ramifications of the above security issues presented by the protocol. Here are few HTTP configuration checklist to help you out:
- When configuring your HTTP server, never use raw IP addresses to allow access to your pages. Otherwise, you will end up with a bunch of them in your access list, which only will make maintenance harder.
- If you ever have problems with misconfigured clinet's domain server, have them contacting the LAN or systems administrator to fix it so you can reverse their names correctly. If you are the one to fix the problem, take the time and do it! In a the long run you will be thankful for it as otherwise, you may end up with a huge list of raw IP addresses on your list.
- You have to deal with access.conf files, make sure to put only one name
Go To Page: 1 2
