Security Audit - Configuring to Avoid Exploits

[vsorensen]

I recently received the results of a security audit on my application, and there were several weaknesses that I couldn't figure out how to plug.  Are there settings I could change for any of the following situations?

(1) When authenticating a user, the application does not assign a new session identifier, but reuses the existing session identifier created before the authentication step. The attack consists in causing a legitimate user to authenticate with a session identifier known to the attacker, and then usurp the session once authenticated using this same identifier. The attacker must create or retrieve a valid session ID and have the victim's browser use it. Depending on the case, this can be done by transmitting the identifier as a URL argument, in a hidden form field or through cookies. *** I see that there is generated code saying "s_web._SitesQueue.Defaults.ChangeSessionOnLogInOut = 1", wouldn't that have prevented this? ***

(2) HTTP header injection in the server response. An injection of HTTP header is possible when user input is returned without being properly escaped in a response header. If a carriage return is retranscribed as is from the request to a response header, an attacker could modify the contents of the following headers, see write a completely different server response. Any Cross-Site Scripting (XSS) attack can usually be reproduced by a header injection, forcing the execution of arbitrary JavaScript. This type of vulnerability can also be used to poison the cache of a proxy serving as an intermediary for users to access the application. Finally, this type of vulnerability can make it possible to pass certain restrictions on authentication flows (CSP / CORS) and the origin of accepted scripts.

(3) Attack by Cross Site Scripting (XSS by Reflection). Parameter values sent by the client browser to the web application are not sufficiently controlled, which could allow an attacker to inject HTML or JavaScript into it.  Indeed, the interpretable characters, such as <,>, /, ', ", etc. are not encoded before they are integrated with the response to the client. This vulnerability could be exploited by an attacker to conduct a Cross-Site Scripting (XSS) attack, in order to execute code in the context of the victim's web browser. This type of attack is usually used to access session cookies, allowing the attacker to impersonate the victim on the application.

(4) Denial of service by renegotiation SSL / TLS. The TLS / SSL service allows renegotiation of sessions initiated by the client. Session renegotiation is an operation that requires a larger amount of computation on the server side than the client side, depending on the algorithm used. An attacker could exploit this phenomenon by requesting a large number of renegotiations of concurrent SSL / TLS sessions in order to trigger a denial of service, bypassing, for example, the mitigations limiting the number of TCP sessions opened by IP (only one TCP session needed for this attack).  *** Is there a way to limit the number of attempts? ***

(5) Value of session cookies predictable or insufficiently random. Cookies are files stored by the web browser of the visitor to a website and which serve (among other things) to identify a user in time, to prevent him from returning to each page his username and password. However, when the cookie values are predictable or insufficiently random, an attacker can potentially impersonate a user by recreating the cookie on their own machine. The auditors noted the possibility of limiting the complexity of the session token returned by the application at the time of authentication. In addition to the acceptance of session cookies presented in TEC.WEB.018, the session token seems to conform to the size and composition of the one provided by the user:
Indeed, if the client provides, at the moment of authentication, a cookie of 2 uppercase letters, the returned cookie will also consist of 2 capital letters. Recommend modifying the application providing the session cookies so that the value of the latter follows a random distribution.  *** I have the session ID length set to 30, is this not the same thing? ***

Issues with possible solutions:
(1) Problem: BEAST Vulnerability (TLSv1.0 with CBC), Vulnerability LUCKY13 (CBC with TLS). LUCKY13 is a time attack against TLS implementations using the weaknesses of the CBC mode (block ciphering). The attack allows the decryption of TLS traffic. Details of the attack can be found at https://eprint.iacr.org/2015/1129.pdf. BEAST is an attack against the TLSv1.0 protocol using weaknesses in the CBC mode (block ciphering). The attack decrypts the SSL / TLS traffic. Full details of the attack can be found in the paper "Here Come The XOR Ninjas" by Thai Duong and Juliano Rizzo, available at: https://bug665814.bmoattachments.org/attachment.cgi?id=540839  ... Solution:  In ThisWebServer.Open, set SELF.SSLMethod = NET:SSLMethodTLS_PCI 

[urayoan]

vsorensen, what version of NetTalk are you using?

[bshields]

1 - ChangeSessionOnLogInOut=1 wont fix this. In reality the attacker must "suggest" via URL a session ID that is both valid (which can be anything) and authenticated. If it is not authenticated it will be changed by NT when it is authenticated. The attacked cannot provide an unauthenticated sessionID and wait for the user to authenticate and then usurp it. Which is what #1 is stating, so its false.

2 - I've not tried this but I see their point. I'll give it a go later. I cannot think of a place where the users input is in the header for this to work. For example: suggest a sessionID with a CRLF that is not escaped and try and trick the header into creating a new line where I could pass other header arguments I could then maybe run scripts from another untrusted domain. I'm pretty sceptical of this "weakness" being exploitable in any meaningful way.

3 - This is a concept in theory. You may or may not have this weakness. I couldn't cause the problem within one of my systems but yours might be different. Its a bit like SQL injection. If you never accept an argument from the url or a posted field value that is used within a sql instruction you cannot get an sql injection. The same applied here, if you never accept a field value that is then in turn directed used within a html tag, you cannot get it. NT does a great deal to protect you from this. All the places you see it giving you a tick box saying allow unsafe XHTML, is a candidate for this weakness, but only if you tick the button (but certainly not guarantee to be a weakness - just a possibility). I'd argue NT is much stronger than most web languages in this respect as by default you are always protected. So #3 is a long bow to draw and they don't appear to have sighted any actual examples, which if they had found the weakness they could have.

4 - This is a bit tricky as SSL renegotiation is a important part of the protocol. There is a simple method of defeating this but its more in Bruces area than mine. This link (https://devcentral.f5.com/articles/ssl-renegotiation-dos-attack-ndash-an-irule-countermeasure) shows how the guys at F5 (firewall company) beat this issue. They just killed any client who tried to renegotiate SSL too often.

5 - I was able to "suggest" a sessionID to NetTalk via the url, but upon successful login it generated and replaced the suggested session cookie with a random one. So in my view #5 is wrong.

Oh, I should have mentioned I tested this on NT10.25.

Regards
Bill Shields

[Bruce]

Hi Vince,

As Ura points out, your report, without a NetTalk version number is meaningless. Security is a process, not an event, and there are constantly things changing. I will assume you are using build 10.33 - if not your first step for maximum security should be to update (and remain more-or-less updated.)

>> When authenticating a user, the application does not assign a new session identifier, but reuses the existing session identifier created before the authentication step.

WebServer, Template, Security tab, "change Session ID on login/Logout". Should be on, and should solve this issue. You can check by inspecting the session ID passed in the cookie before a login, and after a login. I suspect you have this Off.

>> HTTP header injection in the server response. An injection of HTTP header is possible when user input is returned without being properly escaped in a response header.

I believe this is handled in current builds, but assuming you are using a current build, more information (if possible) would be nice. Some audit reports allow you to dig deeper into a report offering a sample of the request and so on.


>> (3) Attack by Cross Site Scripting (XSS by Reflection). Parameter values sent by the client browser to the web application are not sufficiently controlled, which could allow an attacker to inject HTML or JavaScript into it.  Indeed, the interpretable characters, such as <,>, /, ', ", etc. are not encoded before they are integrated with the response to the client.

Again, this may be because you are on an old build, or it may be specific to your application. Ideally again, some sort of example would be welcome to narrow down the context.
From your point of view you should not allow the user to "enter" HTML, and then "display" that without it first being checked. Most importantly you would never set "Allow Unsafe HTML" for this sort of data. "Safe" HTML may display what they enter, but won't be allowed to run any JavaScript. UnSafe HTML allows JavaScript.

>> (4) Denial of service by renegotiation SSL / TLS. The TLS / SSL service allows renegotiation of sessions initiated by the client. Session renegotiation is an operation that requires a larger amount of computation on the server side than the client side, depending on the algorithm used.

It's possible to turn off Session Renegotiation at the OpenSSL Layer. I'll endeavor to do this for the next build.

>> (5) Value of session cookies predictable or insufficiently random.

I suspect this is tied to number 1. If you don't have the "change on login" set then the sessionId suggested is the sessionId used, and this does not change before and after login.
BUT it does raise the issue that suggested cookies may be "too short". So I've tweaked the server so that in future suggested cookies HAVE to be at least the required length (30 chars by default) or they are ignored.

[vsorensen]

Thank you - Sorry for the delay in responding, I was ill last week.

I had 10.33 installed, but the audit was done on my product by a third party for one of my French clients without my input, and they used an older version for that because that's the one they had in production.  I tried to weed out the items that newer versions had fixes for.  (Change Session ID is on.)

I've downloaded 10.35 - thank you for the modification of the minimum cookie length.  I'll watch for the Session Renegotiation option, and see if I can get better examples from the client on the cross site scripting issue, and insist on them using the current version in any future audits.  It's a huge waste of time to be looking for problems that aren't there anymore.