HTTPS
The HTTP protocol uses plain TCP as its transport mechanism, which is unencrypted and so can be intercepted by an attacker who is suitably positioned on the network. HTTPS is essentially the same application-layer protocol as HTTP, but this is tunneled over the secure transport mechanism, Secure Sockets Layer (SSL). This protects the privacy and integrity of all data passing over the network, considerably reducing the possibilities for noninvasive interception attacks. HTTP requests and responses function in exactly the same way regardless of whether SSL is used for transport.
HTTP Proxies
An HTTP proxy server is a server that mediates access between the client browser and the destination web server. When a browser has been configured to use a proxy server, it makes all of its requests to that server, and the proxy relays the requests to the relevant web servers, and forwards their responses back to the browser. Most proxies also provide additional services, including caching, authentication, and access control.
There are two differences in the way HTTP works when a proxy server is being used, which you should be aware of:
■ When a browser issues an HTTP request to a proxy server, it places the full URL into the request, including the protocol prefix http:// and the hostname of the server. The proxy server extracts the hostname and uses this to direct the request to the correct destination web server.
■ When HTTPS is being used, the browser cannot perform the SSL handshake with the proxy server, as this would break the secure tunnel and leave the communications vulnerable to interception attacks. Hence, the browser must use the proxy as a pure TCP-level relay, which passes all network data in both directions between the browser and the destination web server, with which the browser performs an SSL handshake as normal. To establish this relay, the browser makes an HTTP request to the proxy server using the CONNECT method and specifying the destination hostname and port number as the URL. If the proxy allows the request, it returns an HTTP response with a 200 status, keeps the TCP connection open, and from that point onwards acts as a pure TCP-level relay to the destination web server.
By some measure, the most useful item in your toolkit when attacking web applications is a specialized kind of proxy server that sits between your browser and the target web site and allows you to intercept and modify all requests and responses, even those using HTTPS.
HTTP Authentication
The HTTP protocol includes its own mechanisms for authenticating users, using various authentication schemes, including:
■ Basic — This is a very simple authentication mechanism that sends user credentials as a Base64-encoded string in a request header with each message.
■ NTLM — This is a challenge-response mechanism and uses a version of the Windows NTLM protocol.
■ Digest — This is a challenge-response mechanism and uses MD5 checksums of a nonce with the user’s credentials.
It is relatively rare to encounter these authentication protocols being used by web applications deployed on the Internet, although they are more commonly used within organizations to access intranet-based services.
C O M M O N M Y T H “Basic authentication is insecure.”
Basic authentication places credentials in unencrypted form within the HTTP request, and so it is frequently stated that the protocol is insecure and should not be used. But forms-based authentication, as used by numerous banks, also places credentials in unencrypted form within the HTTP request.
Any HTTP message can be protected from eavesdropping attacks by using HTTPS as a transport mechanism, which should be done by every security-conscious application. In relation to eavesdropping at least, basic authentication is in itself no worse than the methods used by the majority of today’s web applications.
NEXT is ..Web Functionality…..,
