For the restriction of access to the paginas of configuration of the tool proposal, one becomes necessary the control through key and password, in which some authorized people will only have access. This mechanism of authentication through key and password for the configuration of the tool directly interacts with the system of security of the machine Unix.

By questions of security guard in the access the information, all pages HTML that are shown by the tool are stored in another area of the record, not being part of the structure of directory of the WWW server. These pages are salutes without the extension standard " html or htm ", not to be identified. As they do not possess the characteristic extension of pages HTML nor are part of the structure standard of directory of the WWW server, he is impossible that they are had access directly through a Browser WWW, being its possible access only through a program cgi that mounts these pages knowing in which archives they is stored and in which directories of the machine Unix it is possible to find them. An exception for this rule exists, that is, the first page is only accessible directly through the WWW server, therefore it will be through it that all the too much functions are had access. The too much pages of the tool alone will be had access if the key and the password of the administrator will be informed.

5. CONCLUSION

No matter how hard tools exist that obtain to block some of the technologies mentioned in this document, as it is the case of the Firewalls and some anti-viruses, will always appear a new technology or the combination of them that they will be used to apply attacks to the users of the Internet.

So that the results of these attacks were minimized, therefore an effective control on all the Browsers WWW of an Intranet is impracticable, appeared the solution displayed in session 4 of this document, that bar the act of receiving of executable contents in the entrance of the Intranet, leaving to only pass when the place of origin of the executable content is known and was configured by the administrator of the tool so that its act of receiving was accepted.

This is not the best solution for the problem a time that the improvement of the quality of the documents that use executable contents is substantial, and the solution proposal in session 4 guarantees the security but it restricts the act of receiving of these technologies of places only known. No matter how hard an executable content is trustworthy, if not to be part of the relation of known and authorized places, its act of receiving is denied.

Some studies exist that include digital signatures in the executable contents for the same ones can identify the origin, as it is the case of the ActiveX controls, but exactly thus this do not decide the problems of security generated by the use of these technologies, therefore no matter how hard a code has a digital signature nobody guarantees the result of its execution.

To decide the problems any executable content that was received by a Browser WWW would have to pass for Models of Security standard created in the Browser WWW for the execution of the same ones, as it is shown in figure 5,1. This model of security is that it would go to allow that an executable content could be processing, independe of the technology that was used for the creation of exactly.

For this a standardization in the use of the executable contents is necessary, that is, the executable contents first would be executed and analyzed for the Model of Security it stops later its execution being applied to the Browser WWW.

This strap of the languages that develop executable contents the task to create alternative mechanisms to decide the problems of security generated by badly projected solutions and many times badly implemented.

BIBLIOGRAPHY