Web client security
As there is more and more awareness about security, we invested in tests and enhancements on our web clients. This resulted in improved security against a wide range of potential threats.
Penetration testing was done on our web client. All critical and potentially high issues coming out of this regarding Cross-Site Scripting (XSS), information leakage, insufficient authentication, content spoofing, predictable resource location, SQL injection are fixed.
Cross site scripting (XSS)
- Stored XSS: these generally occur when user input is stored on the target server. The data can be retrieved from the web application without being made safe to render in the browser.
- Reflected XSS: these occur when user input is immediately returned by a web application in an error message, search result or any other response that includes some or all of the input provided by the user as part of the request. This happens without that data being made safe to be rendered in the browser and without permanently storing the user provided data.
Our Classic ASP pages were fixed by using the reform libraries provided by the https://www.owasp.org/ encoding project. (ASP).NET pages make use of the build-in libraries from the .NET Framework.
Cookies
Cookies are now verified to be Secure, so preventing cookies from being observed by unauthorized parties; and HttpOnly which helps mitigating the risk of client side scripting accessing the protected cookie (if the browser supports it).
HTTP Response Headers
X-Powered-By, X-AspNet-Version and Server are removed through web.config configuration and assisted by an HttpModule called RemoveVersionHttpResponseHeaderModule. Response headers now no longer reveal information like [TS-10481|TS-10093]
Server: Microsoft-IIS/8.5
X-AspNetMvc-Version: 5.2
X-Powered-By: ASP.NET
SQL Injection
This basically consists in inserting a SQL query via the input data form from the client to the application. A successful injection exploit can read sensitive data from the database, modify data, execute administration operations, ...
During the scans there was no evidence found that this is an issue for our web client. Overall, Content Manager's web client is build up with a dedicated Data Access Layer which fully relies on techniques like parameter binding.
Insufficient Transport Layer Protection
SSL/TLS has a good version negotiation mechanism that should prevent a browser (and .NET client applications) and server that support a modern TLS version from using anything less. However, because some servers are buggy and don't implement version negotiation correctly, browsers break this mechanism by retrying connections with lesser SSL/TLS versions when TLS handshaking fails. By injecting some trivial errors on the network, an attacker can cause a browser to speak SSL3 to any server and then run the above attack.
The essence is that client and server can be forced to handshake down to the minimal common intersection of protocols supported which out of the box is an SSL 3.0 that has a serious security risk (POODLE attack).
We've adapted our client tools to no longer accept a protocol handshake resulting in SSL3 overwriting the out-of-the-box .NET runtime behavior. [TS-9114|TS-9428]
You can also avoid the usage of protocol SSL3 by no longer allowing it on your server as described on https://technet.microsoft.com/; this will also make it work for web browsers.