Vulnerable Transmission of Credentials
If an application uses an unencrypted HTTP connection to transmit login credentials, an eavesdropper who is suitably positioned on the network will of course be able to intercept them. Depending on the user’s location, potential eavesdroppers may reside:
■ On the user’s local network
■ Within the user’s IT department
■ Within the user’s ISP
■ On the Internet backbone
■ Within the ISP hosting the application
■ Within the IT department managing the application
Even if login occurs over HTTPS, credentials may still be disclosed to unauthorized parties if the application handles them in an unsafe manner:
■ If credentials are transmitted as query string parameters, as opposed to in the body of a POST request, then these are liable to be logged in various places — for example, within the user’s browser history, within the web server logs, and within the logs of any reverse proxies employed within the hosting infrastructure. If an attacker succeeds in compromising any of these resources, then he may be able to escalate privileges by capturing the user credentials stored there.
■ Although most web applications do use the body of a POST request to submit the HTML login form itself, it is surprisingly common to see the login request being handled via a redirect to a different URL with the same credentials passed as query string parameters. Why application developers consider it necessary to perform these bounces is not clear, but having elected to do so, it is easier to implement them as 302 redirects to a URL than as POST requests using a second HTML form submitted via JavaScript.
■ Web applications sometimes store user credentials in cookies, usually to implement poorly designed mechanisms for login, password change, “remember me,” and so on. These credentials are vulnerable to capture via attacks that compromise user cookies, and in the case of persistent cookies, by anyone who gains access to the client’s local file system. Even if the credentials are encrypted, an attacker can still simply replay the cookie and so log in as a user without actually knowing her credentials.
Many applications use HTTP for unauthenticated areas of the application and switch to HTTPS at the point of login. If this is the case, then the correct place to switch to HTTPS is when the login page is loaded in the browser, enabling a user to verify that the page is authentic before entering credentials. However, it is common to encounter applications that load the login page itself using HTTP, and switch to HTTPS at the point where credentials are submitted. This is unsafe, because a user cannot verify the authenticity of the login page itself and so has no assurance that the credentials will be submitted securely. A suitably positioned attacker can intercept and modify the login page, changing the target URL of the login form to use HTTP. By the time an astute user realizes that the credentials have been submitted using HTTP, they will have been compromised.
NEXT is..Password Change Functionality………….,.,.,.
