HTTP Security

HTTP Security

HTTP is used for Internet communications, so developers of applications, information providers, and users should be aware of the security restrictions in HTTP/1.1. This discussion does not include definitive solutions to the issues mentioned here but makes some suggestions to reduce security risks.

Personal Information Leakage

Often, HTTP clients are confidential to large amounts of personal information such as user name, location, mail address, passwords, encryption keys, etc. So you should be very careful not to involuntarily leak this information to other sources via the HTTP protocol.

• All the confidential information should be kept in encrypted form on the server.
• Revealing the server's specific software version could make the server machine more vulnerable to software attacks which are known to contain security holes.
• Proxies serving as a portal through a network firewall should take special precautions concerning the transfer of header information identifying the hosts behind the firewall.
• The information sent in the 'From' field may conflict with the privacy interests of the user or the security policy of their site, and therefore should not be transmitted without the user being able to deactivate, enable and modify the field contents.
• Clients should not include a Referer header field in a (non-secure) HTTP request if a secure protocol was used to transfer the referring page.
• Service authors using the HTTP protocol should not use GET-based forms for submitting sensitive data, as this will cause the data to be encoded in the Request-URI.

File and Path Names Based Attack

The document should be limited to the documents returned by requests from HTTP to be only those intended by server administrators. Unix, Microsoft Windows, and other operating systems, for example, use '..' as a path component to indicate a directory level above the current level. An HTTP server on such a system MUST disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible through the HTTP server.

DNS Spoofing

Clients using HTTP rely heavily on the Domain Name Service, and are therefore generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. So clients must be cautious in assuming the continued validity of an association of IP number / DNS name. If HTTP clients cache the results of hostname searches to achieve a performance improvement, they must observe the DNS-reported TTL information. If HTTP clients do not observe this rule, they may be spoofed when the IP address of a server that has been previously accessed changes.

Location Headers and Spoofing

If a single server supports multiple organizations that do not trust each other, then the values of the Location and Content-Location headers must be checked in the responses generated under the control of those organizations to ensure that they do not attempt to invalidate resources that they have no authority over.

Authentication Credentials

Existing HTTP clients and user agents typically retain information about the authentication indefinitely. HTTP/1.1 does not provide a server method for directing clients to discard these cached credentials which represent a major security risk.

There's a number of work around the parts of this issue, so it's recommended to use password protection in screen savers, idle time-outs, and other methods that mitigate the inherent security issues in this issue.

Proxies and Caching

HTTP proxies are men-in-the-middle, and are a chance for man-in-the-middle attacks. Proxies have access to information related to security, personal information about individual users and organizations, and proprietary information belonging to users and providers of content.

Proxy operators should protect the systems where proxies are running, as they would protect any system that contains or carries sensitive data.

Caching proxies provide additional potential vulnerabilities since the cache contents are an attractive target for malicious use. Thus the content of the cache should be protected as sensitive information.