Security Vulnerabily XSS | 2017-04-17

Security Audit Vulnerabilities and Suggestions

XSS are security loopholes that attackers can use to be detrimental to the site. The most common are scripts that override UI inputs and cause the user to do unintentional actions. Usually loopholes are found via security audits which financial companies are required to have once a year. Almost always there are critical or high priority items to change because security cypher’s change, low risk threats last year are sometimes critical threats next year. Essentially, security threats never change but these minimum requirements aren’t pushed to the website owner, it’s assumed. Below I’ll list a few things you can do to hit the minimum for 2016

Insecure Transport: Weak SSL Cipher

Generally a TLS and SSL have protocols that help protect authenticity, confidentiality, and integrity of data between a client and a web server. The strength of this protection is determined by authentication, encryption and hashing algorithms known as a cipher suite. Most web servers have cipher suites for varying strengths. If this cipher is weak or an encryption key isn’t long enough, an attacker could steal or modify sensitive data. On any web page you can view the cipher used in the dev tools, security tab and find the Obsolete Connection Settings. It will list something like this:

Viewing Cipher used by any site

Recommendations usually change, in 2016, it is required to be above 112 bits and off of RC4 ciphers. Generally, this means 128 or 256 bit with AES and either DHE or RSA.

Cross Frame Scripting

Usually, XFS vulnerabilities allow an attacker to load the vulnerable application inside an HTML iframe tag. The attacker could use this weakness to devise a clickjacking attack for phishing, frame sniffing, social engineering, or cross site request forgery attacks.

Recommendation is to set the X-Frame-Options header to one of the following options: deny, sameorigin, allow-from. A second requirement is to protect older browsers with client-side JavaScript to protect against XFS because X-Frame-Options isn’t available in all browsers.

Insecure Transport: Weak SSL Protocol

Transport Layer Security provides a mechanism to better protect authenticity, confidentiality and yada. TLS protocols have went through various revisions resulting in periodic updates and it’s recommended to use the latest version. Specifically, you can no longer be on TLS 1.0 because it’s considered weak and will allow attackers to read and modify data on a secure connection.

Viewing Protocol TLS 1.2 used by any site

Here we see TLS 1.2 used and their recommendation is to use above TLS 1.0, but still mark it as high priority to change it to the latest TLS protocol

Cookie Security: Cookies Not Sent Over SSL

When web applications use cookies, they are only considered secure when they are sent via SSL during an SSL session. In other words, it has to be marked as Secure and only sent to HTTPS (HTTP over SSL) servers.

Cookie Security: Persistent Cookies

Cookies are usually used to pass information between pages and store variable information, applications use that data. Usually it’s session id’s, personalization and customization information and sometimes allow automated or persist logins. Session cookies only live on the browser’s memory and not anywhere else, but persistent cookies are stored on the browsing clients hard drive even when that client is no longer browsing the web site which set it.

Essentially, they are used by “Expires=” tag followed by a date in the future, this is found in the Set-Cookie header. Recommendation is to remove the “Expires=” tag from the cookie, which then makes it a session cookie rather than a persistent cookie.

Missing Logout Interface

For Single Sign On applications, logout buttons may not have existed, but they need to so the user can immediately terminate the active authentication session.

Missing Session Timeout

Applications must have an idle session timeout. Essentially, authenticated users maintain an authenticated state indefinitely without re-authorization on subsequent requests to the server. Having indefinite access places personal information and application at risk.

It’s recommended to time out of both the server side and client side after a period of inactivity.

HTTPOnly not set

Cookies have to be HTTPOnly, this requirement it mitigates Cross-Site Scripting attacks by not allowing cookies with the HTTP only attribute to be accessed via client-side scripts. Other requirements are to ensure proper filtration of user-supplied data, utilizing client-side validation and encoding all user supplied data, doing all of these prevents inserting scripts being sent to end users in a format that can be executed.

Autocomplete Password fields

Most browsers have features that save password field content and autocomplete password entries the next time the field is encountered. This feature is enabled by default and could leak password since it’s stored on the hard drive of the user. Though fixing this issue is a tough one because many modern browsers do not support autocomplete=”off” and their suggestion is to fix this issue for older browsers only and not to consider new browsers.

Security Vulnerabilities - Analysis, Suggestions and thoughts

After getting the list of low, medium, high, and critical items; we took the critical and later on the high items and created JIRA stories. After reviewing these stories, I found that our site was already doing what they are saying and later we found that “these are just recommendations”. So project had a first phase of finding the delta, so what the requirements are vs what we are doing because their stated “failures” or “critical” items were inaccurate. It’s a tight rope walk and hard to do right.