Description

Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.

Examples

Scenario #1

A site simply doesn’t use SSL for all pages that require authentication. Attacker simply monitors network traffic (like an open wireless or their neighborhood cable modem network), and observes an authenticated victim’s session cookie. Attacker then replays this cookie and takes over the user’s session.

Scenario #2

A site has improperly configured SSL certificate which causes browser warnings for its users. Users have to accept such warnings and continue, in order to use the site. This causes users to get accustomed to such warnings. Phishing attack against the site’s customers lures them to a lookalike site which doesn’t have a valid certificate, which generates similar browser warnings. Since victims are accustomed to such warnings, they proceed on and use the phishing site, giving away passwords or other private data.

Scenario #3

A site simply uses a standard database connection. If the database and web server are in different physical locations then the information (e.g. database name, user, and password) can be viewed as it goes across the network.

Mitigation

Providing proper transport layer protection can affect the site design. It’s easiest to require SSL for the entire site. For performance reasons, some sites use SSL only on private or sensitive pages. However the overhead of SSL is not that great and it is rarely worth the gain in performance considering the risk of not encrypting sensitive information. At a minimum, do all of the following:

  1. Require SSL for all sensitive pages. Non-SSL requests to these pages should be redirected to the SSL page. Redirection should occur globally for all sensitive areas, not via an included script on each page. (e.g. wordpress users: do not rely on wordpress settings to enforce SSL encryption. It is easy to miss this setting or overwrite it during an upgrade. Instead rely on the web server to require SSL encryption for the entire directory).
  2. Set the ’secure’ flag on all sensitive cookies.
  3. Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.
  4. Do not use self-signed certificates as this "trains" users to ignore invalid certificate warnings.
  5. Backend and other connections (e.g. database connections that go across the network) should also use SSL or other encryption technologies.