Cookies are not (only) for eating

HTTP provides a mechanism for authentication that ask the browser either to send the username and the password more or less in clear text to the server (Basic authentication) or in a hash (Digest authentication). Believe it or not, but Digest authentication was and is a problem for some browsers, so practically only Basic authentication can be used in all environments. Common denominators tend to be small. Plus it is difficult to ask the browser to forget the username and password that has been entered after a certain time; it will be pretty much there as long as the browser is running.

Because of this, web servers started to use another technology, called “cookies”. There you can control how long a session will be valid and you can also control the layout that the user will see when logging in. This is today pretty much standard. And so we thought this is how you should log into the m9.

The m9 keeps all information related to a login session in a special object inside the built-in web server; not only the login credentials, but also session variables. For example, the identity that the user has chosen is stored in this session variable. Another one is the duration, after which the session will expire.

The snom m9 stores the cookies temporarily. Many users are concerned with permanent cookies (including me), and browsers today make a big distinction between permanent and temporary cookies. So there should be no problem. If you use the HTTPS transport layer, then the cookies will be exchanged between the browser and the snom m9 in an encrypted fashion, so that outside parties will not be able to see them in clear text. Because the web server does not care where the request comes from, it would be possible, if you know the session cookie, to resume the session from another computer; in other words, you could skip the login part and start editing user data just like that or use the powerful debugging possibilities as admin to do other bad things.

There was recently a report that it would be possible to steal the cookies (BEAST). This attach assumes that someone is able to execute JavaScript in the web page for the m9. I am not the biggest security expert, but I think that would assume that the attacker must be able to modify the files on the m9 file system; which would be pointless because once someone can do that, this guy can also read the configuration in clear text which would be a shortcut to all secrets on the system and he can skip tricky TLS problems.

Injecting JavaScript is admittedly a big problem with many web sites, for example when you receive a call from “<script type="text/javascript">document.write('<b>Hello World</b>');</script>” (that would be the display name in the SIP URI) and that is being shown in the call history of the web page. However, there are few places where such content is being printed out on the web page, and we made sure that such text is properly encoded in HTML, so that the browser does not misunderstand this as HTML that should be executed. Because the m9 does not have too many web pages, it is relatively easy to do that compared to huge web sites (e.g. for bank), where such a check will be a lot more work!