This article demonstrates common security concerns and vulnerabilities of an application due to vulnerable SSL/TLS Protocols, Set-Cookie Attributes with Secure and HttpOnly flag. This is a continuation of series of discussions on common security concerns and vulnerabilities. You can refer to related articles on this topic.
Related Article,
In this article, we will discuss some of the common web security concerns with remediation techniques related to,
- Vulnerable SSL/TLS Protocols
- SSL Cookies – Secure Attribute Not Set
- Cookie without HttpOnly Flag Set
Vulnerable SSL/TLS Protocols
Some SSL/TLS services were found to support vulnerable SSL protocols. There is a risk that a highly skilled malicious user, correctly positioned on the network, could perform a Man-in-the-Middle (MitM) attack.
The following are some of the SSL protocol issues found on the system,
- Implementation of some of the SSL/TLS 1.0 services was found to allow information disclosure should a malicious user intercept the encrypted traffic. The reason for the vulnerability is because of a possible flaw in the implementation of the CBC block cipher’s Initialization Vector (IC) affecting SSLv3 and TLS 1.0. This vulnerability is widely known as initialization vector information disclosure or BEAST.
- Supporting SSLv3/TLS 1.0 which uses nondeterministic CBC padding could allow a man-in-the-middle attacker to decrypt portions of encrypted traffic using a 'padding oracle' attack. This is sometimes referred to as POODLE vulnerability (Padding Oracle On Downgraded Legacy Encryption). Any successful attack on SSL/TLS services could mean that sensitive information such as user credentials would be exposed.
Remediation Technique
It is recommended that SSL/TLS services supporting the vulnerable protocol(s) should be disabled if they are not required. If these services are required, then the following configurations should be applied to any network-accessible SSL services and are considered to be an industry-accepted standard,
- disable support for SSLv3 or lower and TLS 1.0
- only support TLS 1.1 or TLS 1.2
- disable all cipher suites which uses block ciphers such as CBC
SSL Cookies - Secure Attribute Not Set
Sometimes application was found to utilize SSL cookies set without the “Secure” attribute.
SSL cookies without the “Secure” attribute set mean that the cookies could be transmitted through an unencrypted connection from the browser to the server. There is a risk that a malicious user, who is suitably positioned on the network, could eavesdrop and replay the authentication token to gain access to the web application. A “Secure” flag informs a web browser to always send a cookie via an encrypted channel, thus making it harder for an attacker to steal sensitive cookie information.
Remediation Technique
It is recommended that the “Secure” flag is enabled when an SSL cookie is set. An example of a secure cookie is shown below - Set-Cookie: PHPSESSID=XXX; Path=/XXX; Secure; HTTP-Only
![]()
Cookie without HttpOnly Flag Set
The HttpOnly flag was found to not be set on a cookie utilized by the web application.
The HttpOnly flag prevents a cookie from being read or changed by client-side JavaScript. This can make client-side attacks such as cross-site scripting less effective as even if such vulnerability exists, it would not show sensitive cookies. In the current configuration the “accessToken” cookie could be read by a malicious user should a cross-site scripting vulnerability exist within the application.
Remediation Technique
In most cases, there is usually no good reason not to set the HTTPOnly flag on all cookies. The exception being when a legitimate client-side script requires read access to the cookie’s value. Therefore it is recommended to set the HTTPOnly flag if possible
It is recommended that all cookies have the HttpOnly flag set when an SSL cookie is set. An example of a secure cookie is shown below,
Set-Cookie: PHPSESSID=XXX; Path=/XXX; Secure; HTTP-Only
Happy Reading!