Security of HTTP
HTTP is used to communicate over the internet, so users, information providers, and application developers should be aware of the limitations of security in HTTP/1.1. This section does not provide a definitive solution to the problems mentioned here. It provides some suggestions to reduce security risk.
Personal information
In HTTP, clients are often privy to a large amount of personal information like: name of the user, email address, passwords, location, Encryption key, etc. We should be careful to prevent unintentional leakage of this personal information of the client via the HTTP protocol to other sources.
1. Abuse of Server Log Information
In this, all the personal data of the user should be stored at the server in an encrypted form.
2. Transfer of Sensitive Information
HTTP cannot regulate the content of data that is transferred. HTTP cannot have any prior method to determine the sensitivity of any particular part of the information within the context of any request.
Revealing any specific software version of the server might allow the server machine to become more vulnerable to attacks against software which contains security holes.
The Proxies which serve as a portal through the firewall of the network should take special precaution about the transfer of header information which is used to identify the hosts behind the firewall.
3. Encoding Sensitive Information in URI’s
The source of a link could be private information, so it is strongly recommended that the user be able to select whether or not the field of the referer is sent.
If the page that we refer was transferred with a source protocol, clients should not include a Referer field in an HTTP request.
4. Privacy Issues Connected to Accept Headers
Accept request-headers can reveal the client’s information to all servers which are accessed.
Attacks Based On File and Path Names
The implementation of the origin server of HTTP should be careful to restrict the document, which is returned by HTTP requests to be only that were intended by the server administrators.
For example, Microsoft Windows, UNIX, and other operating systems use “–” as a path component which shows a directory level above the current one. On that type of system, an HTTP server MUST disallow any such construct in the Request-URI if it would, otherwise an HTTP server disallow access to a resource those intended to be accessible through the HTTP server.
DNS Spoofing
HTTP clients rely heavily on the DNS (Domain name service), and are thus generally prone to security attacks, which are based on deliberate mis-association of IP addresses and the name of the DNS. So the client should be careful in assuming the continuing validity of an IP address and DNS name association.
If the clients of HTTP cache the results of hostname lookups to improve the performance, they must observe the TTL information, which was reported by the DNS. When the IP address of the previously accessed server is changed, then the HTTP clients could be spoofed if they do not observe this rule.
Location Headers and Spoofing
If the multiple organizations are supported by a single server, and any of the organizations do not trust each other, then it must check the Location value and Content-Location headers in the response that are generated under control of said organizations. These organizations are used to make sure that they do attempt to invalidate resources over which they have no authority.
Authentication Credentials and Idle Clients
User-agent and existing HTTP clients typically retain the information of authentication indefinitely. HTTP/1.1 does not provide any method for a server to direct clients to discard these cached credentials.
To solve this problem, we can encourage the use of idle timeout, password protection, and other methods that reduce the security problems inherent in this problem.