Proposal for standardizing a set of security guidelines for Web applications

Nous avons demandé à l'auteur de ce texte posté dans bugtraq la permission de le republier ici. Il nous semble en effet poser de bonnes questions et nous rappelle fortement une espèce de pulsion qui nous amène, nous, Kitetoa, à publier des papiers sur la qualité toute à fait relative de l'installation de certains serveurs...

Title: Proposal for standardizing a set of security guidelines for web applications
Author: Dan N. (dannydude at cyberdude dot com)
Date: 06/16/10

Introduction:

        Recently, I was disappointed to find out how many important and known companies still have a very weak security model (I am not even talking about Microsoft here). I will discuss two real examples later on. We all know that the security of a service is as strong as "the weakest link in the chain". I figured that so many vendors and services would be aware of this, but unfortunately, I found out that they don't care, and if someone reports it to them, they either deny it or just let the vulnerability exist. In my opinion, there are two kinds of vulnerabilities. The ones that are so basic and ridiculous that they shouldn't be happening, and the ones that exist due the complexity and power of the software. I would like to get your attention focused on one specific problem, which is of course a "ridiculous" issue, namely companies offering web based services with no referer checking, cookie placement and/or session timeouts. While I know this is not a new issue, it is still a big issue and this should be some food for thought.

Examples:

        A few days ago, I found out that a register.com ip checked out a domain name I just setup. Since no one could known about the domain name, and my webserver logs referers, I decided to follow the referer since I would like to know where on their site my new domain was linked. I ended up finding out that this link brings me to their webbased ISP administration software. After doing some tests with some of my domain names, I found out that I was able to change anything from contact info to dns settings. I asked a friend of mine to do the same thing with his domains hosted by register.com, and he was able to do the same thing. This means that anyone, knowing how the site's url structure is setup, can change ANY domain setting for any domain hosted by register.com We all know how many domains they host , and this could have been a serious disaster. This is where the first mistake was made. The referer should have been rewritten by some sort of cgi proxy, or just not allow links to be followed from the webbased administration system. Second, they should have restricted access to this system based on ip's, so outsiders could not even get to the system. Another serious mistake they made was that they did not use any means of timing out sessions. If you try hotmail for example, when you become idle or leave the site, you can not do anything till you authenticate yourself again. The referer I had in my webserver log files was more than a day old! Another mistake they made was the url encoding. The url basically consisted of a SessionID (which didn't seem to matter what it was), a trouble ticket ID,domain name in clear text (!) followed by two numbers, both "1" without quotes. Simply changing the domain name from the referer to any domain I wanted to edit would allow me to actually change things. The url should have been more cryptic, especially the domain name part. Now think of what could have happened if someone else found out about this. They could have changed the MX records of many businesses so whoever has bad intensions can intercept ALL email for those companies and then redirect it back to the original MX server. It couldn't be easier to do corporate espionage and blackmail them. There are more things you can do that are worse (such as changing the dns settings of all the domains, or of register.com itself) causing many websites to fail. Remember, they have over a million members (according to their latest claims). Of course, as soon as I found out about this problem I contacted register.com. There is something else I would like to see change (and if I remember correctly, RFP discussed this in his new policy). When I tried to contact them, most of the times, their automated phone system would hang up on me after several minutes. I asked some other people to try to get a hold of them, but they had no luck either. I am not sure if this was a temporary glitch or what. So I decided to try to contact them by email. After a while I received an email saying they do not read email at all and to use the webbased form. (Great, now internet companies will start refusing to even read e-mail??). Browsing their site for another email address ended up in no results either. And I was not interested in sending an email to Sales. I tried using the webbased form, but they do not even have an entry for a "bug report", so I selected another topic. After entering a detailed description, the program tells me that I should try to delete some parts of my test. I never have had this many problems trying to contact a company with important information. A friend ended up calling for me, and they were basically laughing at him, wondering why register.com should care. Mysteriously, after my friend hung up (after 30 minutes), the problem was fixed. So much for the respect I had for register.com.

        Yesterday, I discovered a similar problem with a known company that hosts websites for free. They also offered email and allowed you to check email using a known webbased program. Using the referer, it would allow you to read & manage any mail (I tried this on my own email account). I did not bother getting into details with this one since I did not have the time and I was pretty sure that if I could do it, anyone can. I will check out later if this was misconfiguration on the host's side, or a flaw in the program.

        This is not something I personally experienced, but just look at the domain hijacking that was going by exploiting some sort of vulnerability or security check at Network Solutions.

Conclusion:

        It is time to write some sort of security guidelines paper (if no one has already) and somehow convince companies that develop webbased products to use these. Many companies depend on outsourced services, and in most cases, there is a webbased interface to manage those outsourced services. I personally wish to see that after a paper like that has been written, that it could be used to hold the software companies responsible when a breach of security happens that could have been prevented by following the guidelines. The paper would basically be a check list, written from suggestions by security experts. Making this paper a standard could prevent many problems. Software companies could then sell their software while claiming that the software follows these particular guidelines. Companies that want to purchase such software could start looking for software that meet these standards to have some additional security. While I realize that this paper could not stop every problem, it could stop many of the "dumb" vulnerabilities and would be a good step in the right direction. Please remember that this article describes some of my recent experiences, an opinion, and a possible solution. Hopefully this article will trigger enough interest to prove why such a paper would be a good, or not a good idea at all.

Note: This article was written in a hurry while I had some time, it may contain some errors, please feel free to correct them if they are significant.

_____________________________________________________________
Lightcore.com!