The 9th item on the OWASP Top 10 is A9 - Insufficient Transport Layer Protection. This is mostly a browser to server and server to server issue.
This is the risk rating from OWASP:
| Threat Agents | Attack Vectors | Security Weakness | Technical Impacts | Business Impacts | |
|---|---|---|---|---|---|
| ______ | Exploitability DIFFICULT |
Prevalence COMMON |
Detectability EASY |
Impact MODERATE |
______ |
| Consider anyone who can monitor the network traffic of your users. If the application is on the internet, who knows how your users access it. Don't forget back end connections. | Monitoring users' network traffic can be difficult, but is sometimes easy. The primary difficulty lies in monitoring the proper network's traffic while users are accessing the vulnerable site. | Applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but not elsewhere, exposing data and session IDs to interception. Expired or improperly configured certificates may also be used. Detecting basic flaws is easy. Just observe the site's network traffic. More subtle flaws require inspecting the design of the application and the server configuration. |
Such flaws expose individual users' data and can lead to account theft. If an admin account was compromised, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks. | Consider the business value of the data exposed on the communications channel in terms of its confidentiality and integrity needs, and the need to authenticate both participants. | |
There isn't all that much special about javascript driven web applications when it comes to Transport Layer Protection. Basically there are tree things to remember:
- Use TLS/SSL for private data
- Set the Secure flag on important cookies (like the session cookie)
- Don't mix content loaded over HTTP with content from HTTPS
- Harden your SSL/TLS config
Use TLS/SSL for private data
Whenever you are handling private data that needs protection, you should employ SSL or TLS. Ideally you should use SSL/TLS not only between your server and the browser, but also between the server and any backend services. The idea is to prevent disclosure or changes to data at an unauthorized network hops.
Set the Secure flag on important cookies
Any cookie used for authentication (like session cookies) need to be protected from disclosure over unsecured links. By setting the Secure flag in the Set-Cookie header when delivering the cookie over HTTPS, the server instructs the browser not to send the cookie when making insecure HTTP-requests. This will make sure the application does not accidentally disclose the cookie.
Don't mix HTTP content with HTTPS
Mixing content delivered over HTTP with HTTPS can quickly lead to demise. This is especially true if the requests in question are delivering HTML, javascript or objects (flash etc.). Consider an application that loads some javascript over HTTP and then later moves to HTTPS. If the javascript delivered over HTTP is kept in the browser also after the application has moved to HTTPS, and attacker could inject or alter the javascript, to later affect the script running in the more secure context. Tools like SSLStrip also demonstrate why login forms etc. should not be delivered over HTTP even if the action URI is on HTTPS. The action URI can simply be altered in flight, and thus the post goes to HTTP or is redirected to a completely different location.
Harden your SSL/TLS config
Default installations of SSL/TLS are often quite insecure. They support low security key lengths and also support insecure renegotiation etc., making them vulnerable to key cracking, BEAST or other Man-in-the-middle attacks. A good tool for checking your SSL/TLS configuration is https://www.ssllabs.com/ from Qualys. This tool will only work for endpoints available directly on the internet, so you may also want to look at SSLScan for internal endpoints.
Resources
